Saat memerintah Roma, Marcus Aurelius memiliki seorang pelayan yang memiliki tugas tidak biasa.

Pelayan ini selalu berada di belakang Marcus.

Setiap kali rakyatnya memberi pujian atau bahkan berlutut kepadanya, pelayan ini akan membisikkan sebuah kalimat ke telinganya.

Sering sekali, saya, meninggi, atas apa-apa yang telah didapat.

Padahal, dunia berputar. Bisa saja, pada waktu yang lain, saya akan berada di tempat yang tidak mengenakkan.

Selesai ditulis Sabtu, 13 April 2024, pada 00:38 di Pelaihari

Who Are You?

Data yang didapat saat melakukan fetch ke API selalu memiliki type 

. Kita tidak pernah benar-benar tahu, apa bentuk dari data tersebut. Untuk itu, saat menerima data, kita harus memastikan bahwa data tersebut sesuai dengan apa yang kita inginkan.

Jika data tersebut berbeda dengan ekspektasi kita, ia harus memunculkan error, bukan malah berjalan normal seperti tidak ada apa-apa.

 menjadi library yang digunakan untuk memvalidasi data dalam tulisan ini.

Saat bekerja dalam tim yang kompleksitasnya menengah ke atas, setidaknya terdapat dua role, yaitu Frontend Engineer dan Backend Engineer. Sederhananya, Frontend adalah seorang yang membuat tampilan web agar terlihat cantik, sedangkan Backend adalah orang di balik layar yang mengelola keluar masuknya data ke database.

Jalur komunikasi paling lazim di antara dua role ini biasanya menggunakan API.

Seorang Backend akan menyediakan endpoint, contoh, 

const resp = await fetch("https://dummyjson.com/products").then((res) =>
  res.json(),
);

console.log(resp);

Kita hidup di dunia yang penuh ketidakpastian. Dan, satu-satu halnya yang pasti di dunia ini adalah ketidakpastian itu sendiri.

Begitu pula halnya yang dialami seorang Frontend.

Misalkan, saat melakukan fetch ke API di atas, kita mendapatkan response seperti berikut:

Data yang didapat adalah data product berupa array, yang berisi object detail dari tiap product. Kemudian data tersebut kita render ke tiap component, untuk ditampilkan. Ada nama product, harga, rating, image, dll. Semua berjalan aman.

Namun ternyata, pada suatu hari dan detik yang tidak kita ketahui, Backend mengubah format data yang diberikan.

Apa yang berubah? Jika dilihat secara sekilas tidak ada yang berubah. Semua terlihat sama. Namun saat dilihat lebih detail, barulah kita sadar, bahwa terjadi perubahan pada salah satu key, dari 

Mari lihat kode di bawah ini. Apa yang terjadi saat kita mencoba melakukan print 

const resp = await fetch("https://dummyjson.com/products").then((res) =>
  res.json(),
);

// seharusnya adalah `price`, bukan `cost`
console.log(resp.products[0].cost); 
// undefined

Dan ketika ditampilkan ke halaman web semua berjalan lancar, tidak ada error. Namun harga dari barang menjadi kosong.

Dengan API yang sama seperti sebelumnya, data response yang diterima, kemudian divalidasi terlebih dahulu, dengan skema data yang kita inginkan. Setelah itu, barulah data digunakan.

import { z } from "zod";

// response didapat dari fetch selalu memiliki type any`
const resp = await fetch("https://dummyjson.com/products").then((res) =>
  res.json(),
);

// definisikan skema data yang diinginkan
const schema = z.object({
  products: z.array(
    z.object({
      id: z.number(),
      title: z.string(),
      description: z.string(),
      cost: z.number(), // <--- masih menggunakan `cost`, bukan `price`
      discountPercentage: z.number(),
      rating: z.number(),
      stock: z.number(),
      brand: z.string(),
      category: z.string(),
      thumbnail: z.string(),
      images: z.array(z.string()),
    }),
  ),
});

// data di-parse menggunakan skema yang sudah didefinisikan
const data = schema.parse(resp);

console.log(data);

 di atas berasumsi key dari harga masih menggunakan  

ZodError: [
  {
    "code": "invalid_type",
    "expected": "number",
    "received": "undefined",
    "path": [
      "products",
      0,
      "cost"
    ],
    "message": "Required"
  }
]

Dan...… error. Itulah yang seharusnya terjadi.

Error terjadi karena skema yang kita definisikan, harus ada key berupa 

 dengan value dengan tipe number. Namun yang didapat, value dari 

Saat data yang didapat tidak sesuai ekspektasi kita, maka dia harus menampilkan error. Tujuannya, agar kita bisa membenahi hal tersebut secepat mungkin.

Rasanya-rasanya kita terlalu jauh melangkah, mari ambil beberapa langkah ke belakang, untuk mengetahui, apa itu sebenarnya 

Zod is a TypeScript-first schema declaration and validation library.

 adalah library untuk mendefinisikan skema dan memvalidasi data. Validasi data diperlukan untuk menjaga dan memastikan konsistensi data, agar programmer bisa tidur nyenyak, tanpa takut data yang digunakan tiba-tiba berubah tanpa sepengetahuan.

Kemudian, import dan buat skema sederhana.

 yang mengharuskan untuk menerima input berupa number. Namun, alih-alih memasukkan number, kita mencoba memasukkan string.

import { z } from "zod";

const rankSchema = z.number(); // skema hanya menerima input berupa number

const rank = rankSchema.parse("2"); // kita mencoba memasukkan string

console.log(rank);

// ZodError: [
//   {
//     code: "invalid_type",
//     expected: "number",
//     received: "string",
//     path: [],
//     message: "Expected number, received string",
//   },
// ];

Hasilnya adalah error. Karena kita memaksa, agar input yang dibolehkan hanya benar-benar number, namun input yang diterima justru string.

Jika input yang dimasukkan benar-benar number, maka hasilnya tidak akan ada error.

import { z } from "zod";

const rankSchema = z.number();

const rank = rankSchema.parse(1);

console.log(rank);
// 1

Mari lanjut untuk membuat skema yang lebih kompleks.

Kita mendefinisikan sebuah skema untuk user bernama 

, data yang di-input harus berupa object, dengan minimal terdapat key 

. Kemudian kita masukkan input data sesuai skema tersebut.

import { z } from "zod";

const userSchema = z.object({
  name: z.string(),
  age: z.number(),
});

const input = {
  name: "Zaki",
  age: 20,
};

const user = userSchema.parse(input);

console.log(user);
// {
//  name: "Zaki",
//  age: 20,
// }

Hasilnya, semua berjalan aman, karena skema dan input sesuai. Bagus.

Kemudian kita coba, seandainya input yang diberikan tidak sesuai. Key 

import { z } from "zod";

const userSchema = z.object({
  name: z.string(),
  age: z.number(),
});

const input = {
  name: "Zaki", // <--– age dihapus
};

const user = userSchema.parse(input);

console.log(user);

// ZodError: [
//   {
//     code: "invalid_type",
//     expected: "number",
//     received: "undefined",
//     path: ["age"],
//     message: "Required",
//   },
// ];

Banyak pilihan type yang bisa digunakan untuk mendefinisikan skema. Berikut beberapa contohnya:

// primitive values
z.string();
z.number();
z.bigint();
z.boolean();
z.date();
z.symbol();

// empty types
z.undefined();
z.null();
z.void(); // accepts undefined

// catch-all types
// allows any value
z.any();
z.unknown();

// never type
// allows no values
z.never();

z.enum(["Salmon", "Tuna", "Trout"]);

Tidak semua value bersifat wajib, kita bisa menjadikannya opsional, misal 

Atau jika kita tidak tahu (atau malas mendefinisikan) kita bisa menggunakan 

Keuntungan lain dari menggunakan schema validation adalah kita bisa sekaligus mendapatkan Type, dari skema yang sudah didefinisikan.

import { z } from "zod";

const userSchema = z.object({
  name: z.string(),
  age: z.number(),
});

type User = z.infer<typeof userSchema>;
//   ^ type User = { name: string; age: number; }

Sehingga, jika kita memerlukan type dari User, sebagai type dari props di sebuah component, kita hanya perlu mengekspornya.

Data yang didapat dari fetch selalu bernilai 

. Kita tidak pernah benar-benar tau, apa bentuk dari data tersebut. Seperti membeli kucing di dalam karung, isinya bisa saja sebenarnya adalah buaya.

Untuk itu, perlu untuk melakukan validasi dari data yang kita dapat.

Berikut beberapa resource yang relevan dengan tulisan ini:

schema declaration and validation library.

Selesai ditulis pada Jumat, 12 April 2024 pukul 23:41 di Pelaihari, Kalimantan Selatan

Selesai disempurnakan pada Sabtu, 13 April 2024 pukul 18:59 di Pelaihari, Kalimantan Selatan

Setiap fetch ke API selalu menghasilkan data dengan type any, jadi saat menerima data, penting untuk memverifikasi kesesuaian data dengan kebutuhan kita

Seni Menerima Data dari Backend, untuk Frontend yang Ingin Tidur Nyenyak

 adalah client first, artinya, saat melakukan update search params, web tidak akan melakukan re-render. Ini hal yang bagus jika value dari search params hanya perlu dibaca melalui client side.

Namun, jika value perlu dibaca oleh server, maka tidak akan terbaca perubahannya. Untuk memicu re-render agar perubahan terbaca oleh server maka perlu ditambah opsi 

 yang mengusung server first, artinya setiap perubahan value akan langsung terbaca oleh server.

Rasakan perbedaan antara search params client side dan server side pada 

Tulisan ini merupakan lanjutan dari tulisan 

Membuat Komponen Search di Next.js App Router

. Jika sebelumnya kita menggunakan library 

, untuk me-manage search params, kali ini kita akan bermain dengan 

Sebenarnya sebelum ini, saya sempat mencicipi 

. Namun karena keterbatasan pengetahuan, akhirnya saya tidak melanjutkannya.

 yang men-trigger saya untuk kembali membaca lebih dalam dokumentasi 

Type-safe search params state manager for Next.js

Mari kita mulai. Tentu saja, framework yang digunakan dalam tulisan ini adalah 

 kita teruskan menjadi search params dengan 

// src/app/client.tsx

'use client'
 
import { useQueryState } from 'nuqs'

export function Demo() {
  const [name, setName] = useQueryState("name");
  return (
    <>
      <input value={name || ""} onChange={(e) => setName(e.target.value)} />
      <p>Hello, {name}!</p>
    </>
  );
}

Mengan perlu menuliskan "use client" pada baris paling atas?

Karena, sejak diperkenalkannya paradigma 

 di Next.js, default dari setiap component adalah server component. Sedangkan, dalam kasus ini, kita memerlukan 

 yang merupakan client component. Sebab itu, perlu untuk menuliskan "use client" pada baris teratas, untuk memberi tahu React, bahwa ini merupakan client component (

Hasilnya, setiap kali memasukkan value di 

, maka search params akan langsung ter-update.

Untuk contoh lebih banyak, bisa dilihat di 

Sebelumnya, saya sempat menggunakan nuqs pada tweet ini. Perbedaan paling mencolok antara 

Kamu bisa merasakan langsung perbedaan client-first (

 mengusung client-first, maka, kita tidak bisa mengakses search params dari server side.

Kemudian, saat mengetikkan input nama, URL berubah menjadi 

 yang kita ambil dari search params akan tetap kosong, 

 secara default tidak men-trigger pembaruan halaman ke server. Sehingga meski kita URL di browser kita berubah menjadi 

, sejatinya, server masih menganggap kita berada pada halaman 

interface Props {
  searchParams: {
    name?: string;
  };
}

export default async function Page(props: Props) {
  const { searchParams } = props;
  const { name } = searchParams;

  return (
    <div>
      value from server: {name}
    </div>
  );
}

Namun berbeda halnya pada client component, seperti pada 

Izinkan saya meletakkan kodenya sekali lagi.

 akan langsung terbaca, meski kita tidak melakukan pembaruan halaman ke server.

, setiap kali melakukan update value pada 

, server langsung mengenali bahwa kita sudah berada di URL 

Setelah melakukan pembacaan lebih seksama, meski 

, kita tetap bisa menjalan re-render, yaitu dengan menambahkan 

Dengan setting-an di atas, maka kita bisa mendapatkan search params melalui server side.

 juga ternyata digunakan oleh vercel.com 😅

, karena tidak perlu menambahkan kode pada fitur layout.

 adalah client-first, maka value dari search params, perubahan value tidak bisa didapat secara langsung pada server side, kecuali menggunakan 

 yang sedari awal adalah server-first, sehingga perubahan value langsung bisa dibaca oleh server.

Alhasil, semua kembali ke sisi developer. Pertanyaannya:

Selesai ditulis hari Kamis, 11 April 2024 pada 13:39, atau hari kedua lebaran.

Sebelumnya, kita menggunakan library next-query-params, untuk me-manage search params, kali ini kita akan bermain dengan nuqs

Bermain Search Params dengan nuqs di Next.js App Router

 agaknya gampang-gampang susah, namun semenjak munculnya App Router, menjadi lumayan susah.

Melalui artikel ini, kita akan belajar bagaimana membuat komponen 

 yang pada setiap perubahannya, akan men-trigger perubahan di search params, seperti 

 untuk membuatnya terhubung dengan search params, dengan mudah. Kemudian menggunakan 

 untuk menambahkan debounce. Dan terakhir, kita akan membuatnya lebih sungguhan dengan melakukan fetch ke dummy API, dengan tambahan pengaman dari 

Ada banyak cara untuk membuat komponen search. Cara paling masyhur adalah menggunakan 

Sayangnya, jika menggunakan Next.js App Router, kita tidak bisa menggunakan 

 begitu saja. Karena server component tidak memperbolehkan itu.

Sebab itu, melalui artikel ini kita akan belajar membuat komponen 

Contoh paling sederhana, saat kita mengetik di kolom pencarian, lalu URL berubah dari 

. Bentuknya bisa berupa string, array of string, atau undefined.

// https://nextjs.org/docs/app/api-reference/file-conventions/page

export default function Page({
  params,
  searchParams,
}: {
  params: { slug: string }
  searchParams: { [key: string]: string | string[] | undefined }
}) {
  return <h1>My Page</h1>
}

// src/app/search/page.tsx

interface Props {
  searchParams: {
    query?: string;
  };
}

export default function Page(props: Props) {
  const { searchParams } = props;
  const { query } = searchParams;

  return (
    <div>
      <div>Query: {query}</div>
      <input className="ring-1 ring-gray-300 rounded-md" />
    </div>
  );
}

Seandainya menggunakan client component, kita bisa langsung mengambil value dari 

<input
  onChange={(e) => {
    console.log(e.target.value);
  }}
/>

Namun yang terjadi jika menerapkannya pada server component (default dari page.tsx) akan menghasilkan error.

Untuk mengakalinya, kita akan memindahkan komponen 

. Kita akan mengumpulkan semua client component di sini.

 di baris paling atas kode, untuk menjadikan semua komponen di file ini adalah client component.

"use client";

export const SearchInput = () => {
  return (
    <input
      className="ring-1 ring-gray-300 rounded-md min-w-full p-2"
      onChange={(e) => {
        console.log(e.target.value);
      }}
    />
  );
};

Jika sudah, saatnya kita mengimport komponen 

// src/app/search/page.tsx

import { SearchInput } from "@/app/search/client";

interface Props {
  searchParams: {
    query?: string;
  };
}

export default function Page(props: Props) {
  const { searchParams } = props;
  const { query } = searchParams;

  return (
    <div>
      <SearchInput />
      <div>Query: {query}</div>
    </div>
  );
}

Dan hasilnya adalah berikut, kita berhasil menggunakan 

 bawaan dari Next.js, kodenya akan seperti berikut:

// https://nextjs.org/learn/dashboard-app/adding-search-and-pagination#2-update-the-url-with-the-search-params

'use client';
 
import { useSearchParams, usePathname, useRouter } from 'next/navigation';
 
export default function Search() {
  const searchParams = useSearchParams();
  const pathname = usePathname();
  const { replace } = useRouter();
 
  function handleSearch(term: string) {
    const params = new URLSearchParams(searchParams);
    if (term) {
      params.set('query', term);
    } else {
      params.delete('query');
    }
    replace(`${pathname}?${params.toString()}`);
  }
}

Namun, saya bukan orang yang rajin untuk menulis 

// https://www.npmjs.com/package/next-query-params#usage

import {useQueryParam, StringParam, withDefault} from 'use-query-params';

export default function IndexPage() {
  const [name, setName] = useQueryParam('name', withDefault(StringParam, ''));

  function onNameInputChange(event) {
    setName(event.target.value);
  }

  return (
    <p>My name is <input value={name} onChange={onNameInputChange} /></p>
  );
}

pnpm add next-query-params use-query-params

. Sedangkan, ada beberapa komponen yang harus menggunakan 

 ini lazim digunakan oleh beberapa library seperti 

// src/app/providers.tsx

"use client";

import { Suspense } from "react";

import NextAdapterApp from "next-query-params/app";
import { QueryParamProvider } from "use-query-params";

export function Providers({ children }: { children: React.ReactNode }) {
  return (
    <>
      <Suspense>
        <QueryParamProvider adapter={NextAdapterApp}>
          {children}
        </QueryParamProvider>
      </Suspense>
    </>
  );
}

// src/app/layout.tsx

import { Providers } from "@/app/providers";

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <html lang="en">
      <body>
        <Providers>{children}</Providers>
      </body>
    </html>
  );
}

 yang telah kita buat sebelumnya pada file 

. Karena kita menggunakan nama "query" maka, menjadi 

 otomatis menjadi string. Selain string, ada juga helper untuk number (

"use client";

import { StringParam, useQueryParam } from "use-query-params";

export const SearchInput = () => {
  const [query, setQuery] = useQueryParam("query", StringParam);

  return (
    <input
      className="ring-1 ring-gray-300 rounded-md min-w-full p-2"
      onChange={(e) => {
        setQuery(e.target.value);
      }}
    />
  );
};

Setiap kali kita mengetikkan value di komponen input, maka URL akan berubah menjadi 

. Dan jika kita hapus, maka akan terhapus pula.

seach-params-playground.vercel.app/search?query=laptop

Setiap kali kita mengetikkan sesuatu di komponen input, maka search params akan berubah, seketika. Sayangnya, hal ini memiliki dampak kurang bagus.

Bayangkan sebuah komponen search yang terhubung dengan API. Setiap user mengetikkan satu huruf, maka satu kali 

 ke endpoint dilakukan. Lalu apa jadinya, jika user mengetikkan 10 huruf? Akan ada 10 

 ke endpoint. Ini bukan hal yang baik. Untuk itu, kita perlu menunggu user selesai mengetikkan pencariannya, barulah kita melakukan 

Alur kerja "menuggu" ini biasa kita sebut 

Untuk menambahkannya ke komponen input, mari kita menggunakan 

"use client";

import { StringParam, useQueryParam } from "use-query-params";
import { useDebouncedCallback } from "use-debounce";

export const SearchInput = () => {
  const [query, setQuery] = useQueryParam("query", StringParam);

  const handleChange = useDebouncedCallback((value: string) => {
    setQuery(value);
  }, 500); // lama waktu menunggu

  return (
    <input
      className="ring-1 ring-gray-300 rounded-md min-w-full p-2"
      onChange={(e) => {
        handleChange(e.target.value);
      }}
    />
  );
};


 dan menunggunya selama 500 ms (0,5 detik), barulah search params akan terupdate.

Tak lengkap rasanya, jika kita tidak membuat implementasi sungguhan dari komponen ini.

 ubah menjadi berikut, tambahkan function 

// /src/app/search/page.tsx

import { z } from “zod”

const getData = async (query: string | undefined) => {
  const schema = z.object({
    products: z.array(
      z.object({
        id: z.number(),
        title: z.string(),
        description: z.string(),
        price: z.number(),
        discountPercentage: z.number(),
        rating: z.number(),
        stock: z.number(),
        brand: z.string(),
        category: z.string(),
        thumbnail: z.string(),
        images: z.array(z.string()),
      }),
    ),
    total: z.number(),
    skip: z.number(),
    limit: z.number(),
  });

  const response = await fetch(
    `https://dummyjson.com/products/search?q=${query}&limit=10`,
  );

  const data = await response.json();

  return schema. Parse(data);
};

export default async function Page(props: Props) {
  const { searchParams } = props;
  const { query } = searchParams;

  const data = await getData(query);

  return (
    <div>
      <div className="mb-2">Query: {query}</div>

      <SearchInput />

      <div className="grid grid-cols-2 gap-4">
        {data.products.map((product) => (
          <div
            key={product.id}
            className="rounded-md border border-gray-300 p-4 my-4"
          >
            <h2 className="text-xl">{product.title}</h2>
            <p className="text-gray-500">Category: {product.category}</p>
            <img
              className="rounded-md w-48 h-48 object-cover"
              src={product.thumbnail}
              alt={product.title}
            />
          </div>
        ))}
      </div>
    </div>
  );
}

seach-params-playground.vercel.app/search

Semenjak munculnya App Router, banyak paradigma lama yang harus dirombak, salah satunya adanya pemisahan client component dan server component.

Awalnya terasa rumit memang. Namun semakin ke sini, saya justru semakin menikmatinya.

Dari awalnya pembenci App Router, menjadi pengguna setiap App Router.

Lanjutan tentang search params, mungkin kamu tertarik membaca tentang 

Selesai ditulis di Pelaihari, 8 April 2024 pada 00.29 AM.

Membuat komponen Search agaknya gampang-gampang susah, namun semenjak munculnya App Router, menjadi lumayan susah

It’s so easy to be great nowadays, my friend, cause most people are weak

”, atau jika diterjemahkan, “Saat ini sangat mudah untuk menjadi orang hebat, karena mayoritas orang-orang sekarang itu lemah”.

Bermula dari tweet di atas, ketika tahu bahwa ada kepala keluarga, yang dengan santainya tidak berpuasa di bulan Ramadan. Padahal dia tidak memiliki keringanan untuk meninggalkan puasa.

Dari topik tersebut, malam itu, obrolan berlanjut ke hal yang lebih mendasar.

Saya mengajukan sebuah pernyataan sederhana, bahwa sekarang ini, (—meminjam ucapan David Goggins), sangat mudah untuk menjadi laki-laki yang berkualitas, mengapa? Karena kebanyakan laki-laki, 

bahkan tidak bisa mencapai standar minimal

, untuk dikatakan sebagai laki-laki baik (biasa).

Mari kita duduk sejenak, dari sekian banyak teman yang kita punya, berapa orang yang memenuhi standar minimal laki-laki “biasa” berikut ini:

Sekali lagi, berapa orang yang kamu tahu memenuhi standar minimal di atas? Saya berani bertaruh, tidak sampai sepuluh persen, dari sekian ratus teman yang ditemui dalam hidup 🤷🏻‍♂️

Semua kriteria di atas masih standar minimal. Seseorang yang memenuhi kriteria tersebut tidak perlu dipuji, itu hal biasa.

Seseorang yang menjaga shalat lima waktunya, itu hal biasa, standar minimal, memang sudah kewajiban, ia tidak perlu dipuji.

Namun karena rendahnya kualitas laki-laki sekarang, saat tidak menjaga shalat adalah hal yang biasa, maka menjaga shalat terlihat luar biasa.

Teringat cerita seorang teman, yang memilih pasangannya, hanya karena hal sederhana, yaitu, ia menemukan pasangan yang menjaga shalat lima waktunya.

Saking banyaknya yang berada di bawah standar. Sesuatu yang menjadi standar minimal terasa mengagumkan.

Kita belum berbicara kemampuan dasar lebih lanjut, yang setidaknya harus dimiliki seorang laki-laki, seperti, 1) paham ilmu agama dasar, mengerti makna syahadat, dan tahu hukum-hukum shalat, dan; 2) bisa menjadi imam, setidaknya bagi keluarga kecilnya.

Lalu kapan seseorang dikatakan memiliki standar yang tinggi, dan patut dipuji? Bagi saya, contohnya, ketika bisa membaca Al-Qur’an dengan pelafalan huruf yang benar, memiliki hafalan beberapa juz Al-Qur’an atau bahkan satu Al-Qur'an penuh, bisa menjadi imam bagi orang banyak, bisa berbahasa Arab, mengerti hukum-hukum agama secara rinci, dan lainnya.

Malam itu, di akhir pembicaraan, saya berucap, ternyata, sebenarnya laki-laki yang walaupun hanya memenuhi standar minimal, memiliki “

” yang kuat. Memiliki posisi jual yang tinggi. Karena sebenarnya kalian adalah manusia langka. Sebab itu, bersyukurlah dan jangan rendah diri. Orang-orang seperti kalian hanya belum “ditemukan” oleh orang yang tepat.

Selesai ditulis di Banjarmasin, 3 April 2024 pada 23:59 (malam ke-24 Ramadan 1445 H)

Sekarang ini, sangat mudah untuk menjadi laki-laki yang berkualitas, mengapa? Karena kebanyakan laki-laki, bahkan tidak bisa mencapai standar minimal, untuk dikatakan sebagai laki-laki baik

Laki-Laki di Bawah Standar Minimal

Banyak hal yang bisa dilakukan dengan GitHub Action. Di antaranya ialah, saya bisa menjalankan script untuk melakukan scraping website KPU, setiap hari, secara otomatis, tanpa harus menjalankannya manual (

). Hal lain yang bisa dilakukan adalah men-deploy website, setiap kali ada code yang di-push ke repository (

Asumsi dari pembaca artikel ini adalah telah mengerti git, untuk membuat repository dan melakukan push ke repository. Serta akan sangat baik jika telah sering menggunakan terminal.

Secara sangat sederhana, GitHub Action adalah server milik GitHub yang bisa kita pinjam untuk menjalankan kode. Kita bisa menjalankan kode kapan saja, misal, kita ingin menjalankannya setiap jam sekali. Atau bisa juga kita ingin menjalankannya setiap ada push ke repository GitHub.

Secara tidak sederhana, GitHub Action adalah platform untuk menjalankan continuous integration and continuous delivery (CI/CD) untuk mengautomasi proses build, test, dan deployment.

Pertama-tama kita harus menyiapkan sebuah folder project di local, misal, kita beri nama, 

.  Untuk membuat script GitHub Action, kita perlu meletakkannya di dalam folder 

/belajar-github-action/.github/workflows/{letakkan di sini}

. Kita bisa bebas memberi nama file apa saja, bahkan kita bisa membuat beberapa file GitHub Action dalam satu repository.

├── README.md
├── .github
│   └── workflows
│       └── run.yml

Ada 3 komponen penting dalam sebuah file Github Action:

Pertanyaan-pertanyaan di atas kemudian tertuang dalam sebuah file Github Action sederhana menjadi:

Banyak hal yang bisa dilakukan dengan GitHub Action