Sebagai seorang frontend developer, kita adalah garis depan yang berurusan dengan user. Dengan pemahaman tersebut, harusnya kita aware bahwa kebutuhan user adalah hal yang jadi prioritas kita dalam mengembangkan sebuah aplikasi. Nah, salah satu kebutuhan dasar dari user tentunya adalah rasa aman untuk menggunakan aplikasi buatan kita a.k.a security.

Kita tentunya enggak mau dong user merasa enggak safe pake aplikasi kita, di sisi lain kita juga enggak mau dong aplikasi yang kita buat masak vulnerable gitu. Ngisin-ngisini (re: memalukan), kecuali kamu developer buat aplikasi pemerintah sih ya, yang udah berkali-kali memang proven bukan hanya vulnerable tapi enggak layak naik production.

Oke back to topic terkait security, kali ini saya pengen buat semacam series untuk membahas hal-hal yang bisa kita perhatikan dan tingkatkan untuk membantu meningkatkan security di aplikasi kita yang hasil akhirnya tentu bisa meningkatkan rasa aman user kita dan jadinya semakin banyak user yang pakai aplikasi kita.

Kenapa dibuat series, soalnya banyak yang bisa dicover, kalo dijadikan satu artikel tu nanti… saya bingung nulisnya, soalnya masih latihan nulis lagi di medium. Hehe

Pada edisi pertama ini, saya mau membahas hal terkait security yang mungkin tidak terlalu familiar, namun ternyata ini cukup penting untuk diimplement. Apalagi jika aplikasi kita melibatkan proses upload content seperti image, yaitu cleaning EXIF data.

EXIF (Exchangeable Image File Format) data adalah informasi metadata yang tersimpan di file gambar, biasanya ini bawaan dari kamera digital atau aplikasi image editor. Beberapa data yang ada di dalam EXIF diantaranya: tanggal & waktu, camera settings, resolusi, lokasi, model device, dan perangkat lunak editing kalo ada.

Dari penjelasan singkat di atas, kita bisa notice kalo ada dua data yang relate dengan security dan privacy, yaitu tanggal dan waktu dan lokasi. Untuk tanggal dan waktu mungkin masih debatable lah ya, tapi kalo lokasi kan sudah masuk ranah privasi meskipun bisa juga dianggap sebagai public data karena bisa ditrack.

Terus enggak issue dong, ash?! Yo issue lah gimana sih…. debatable tu berarti ya bisa berarti “iya”

Balik lagi, kenapa ini penting, karena image ini kan mostly dalam aplikasi kita dia sifatnya publik ya. Semua orang bisa download image itu kalo contentnya memang muncul di layar user, berbeda dengan data sensitive yang mungkin bisa didapatkan kalo emang ada data breach atau leaked.

Dan banyak juga kasus-kasus kejahatan kan bermodalkan track dari 2 data tadi, yaitu tanggal dan waktu sama lokasi. Juga model kamera ataupun data perangkat lunak dapat digunakan juga oleh pihak yang enggak bertanggung jawab untuk attempt eksploitasi keamanan.

So…. what should we do?

Untungnya sebagai frontend developer, kita berinteraksi dekat dengan file-file user yang akan diupload melalui sistem, jadi kita bisa melakukan pencegahan-pencegahan untuk mengamankan data tersebut. Caranya ya jelas, sebelum kita melakukan proses upload ke backend kita perlu melakukan exif cleansing/exif remove.

Bermodalkan library exifremove dari NPM, kita bisa membuat helper seperti ini:

import exifRemover from 'exifremove';

/**
 * Delete Image Exif
 * @description
 * delete exif data from jpg or jpeg image
 * and return clean image
 * @param {string | ArrayBuffer} image
 * @param {any} imageType
 * @returns
 */
export const deleteImageExif = (image: string | ArrayBuffer, imageType: any) => {
  // @ts-ignore
  const buffer = Buffer.from(image);
  const tempBuffer = exifRemover.remove(buffer);
  const blob = new Blob([tempBuffer], { type: imageType });
  const resultImageDeletedExif = new File(
    [blob],
    `temp.${imageType.split('/')[1]}`,
    { type: imageType },
  );
  return resultImageDeletedExif;
};

The usage:

const readerBuffer = new FileReader();
const imageFile = e.target.files[0];

readerBuffer.readAsArrayBuffer(imageFile);
const { type: imageType, size } = imageFile;

readerBuffer.onloadend = (event) => {
  const imageLoaded = {
    previewUrl: URL.createObjectURL(imageFile),
    file: null,
  };
  if (imageType === 'image/jpeg' || imageType === 'image/jpg') {
    const deletedExif = deleteImageExif(event.target.result, imageType);
    imageLoaded.file = deletedExif;
  } else {
    imageLoaded.file = imageFile;
  }
  setFile(imageLoaded.file, imageLoaded.previewUrl, 'image');
};

// Terus tinggal upload deh filenya 

Dah as simple as that, terus apasih manfaat implement ini? Kenapa kita perlu aware terkait ini selain terkait privacy tadi?

• Dalam beberapa kasus, terutama dengan regional yang punya regulasi yang ketat seperti di Eropa, menyimpan data pribadi kaya lokasi tanpa persetujuan pengguna tuh bisa dianggap sebagai pelanggaran hukum. Jadi implementasi seperti ini bisa sangat bermanfaat untuk menghindari masalah hukum terkait privasi
• Data-data EXIF ini juga menambah ukuran file gambar, jadi dengan implementasi ini kita bisa mengurangi ukuran file gambar dan mungkin bisa juga kita implement image optimization helper yang lain di dalamnya
• Relate dengan EXIF yang menambah ukuran file gambar, nyatanya data EXIF ini banyak yang enggak terlalu diperlukan untuk kebutuhan aplikasi kita, jadi yaa… gitu deh

Jadi dengan begini kamu, aku, dia, dan mereka alias kita-kita semua sudah sedikit lebih dekat untuk memberikan pelayanan prima ke user dengan menambah rasa aman user dalam menggunakan aplikasi kita.

Sampai jumpa di edisi selanjutnya, have a great day!

Frontend Security 101: Securing Your Content was originally published in Bahas Javascript on Medium, where people are continuing the conversation by highlighting and responding to this story.

Di dunia per-frontend-an dimana komunitasnya sudah sangat besar didukung dengan library yang silih berganti tapi bentuknya mirip-mirip mungkin kadang kita agak bingung gimana cara memilih library yang cocok untuk aplikasi kita. Atau mungkin kamu sedang dapat task untuk melakukan migration project, tapi library yang dipake di codebase yang lama sudah enggak relevan lagi di jaman sekarang, kamu juga jadi bingung gimana milih library penggantinya.

Sebagai frontend developer yang mungkin belum terlalu familiar dengan dunia per-npm-an, yang mana disitu banyak librarynya yang mirip-mirip dengan popularitas yang sama mirip-miripnya juga, hal ini bisa bikin dilema. Atau enggak?

Soalnya pemilihan library yang tepat ini juga akan membantu kita untuk maintain codebase kita di waktu yang akan datang, tentunya kita enggak mau pake library yang tidak sustainable dan tidak reliable. Nah, mari kita bongkar detail-detail dalam halaman library NPM untuk membantu kita memilih library yang tepat.

Kita akan mulai kulik dari bagian atas ya

Typescript-based library is better than Typescript declaration file

Pertimbangan pertama yang saya ambil adalah untuk memilih library yang dibikin pake typescript alias typescript-based. Sebenernya hal ini penting nggak penting, tapi untuk long-live project saya akan sarankan untuk pilih yang TS-based. Beberapa keuntungan memilih library yang TS-based:

• Ketika kita nantinya akan migrasi ke project yang berbasis Typescript juga, kita tidak perlu melakukan penambahan install type declaration @types/[something]
• Karena typing yang satu set dengan librarynya, kita lebih confident ketika melakukan upgrade library, sehingga tidak ada risiko versi library yang kita pakai sudah naik etapi ternyata type-nya belum terupdate/belum relevan

Fewer dependencies are better

Pertimbangan kedua saya dalam memilih library adalah memilih yang Dependencies nya lebih sedikit. Karena dengan begitu kita tahu bahwa risiko library kita break ketika ada dependecy yang deprecated/discontinue semakin kecil.

Karena enggak lucu library yang biasa kita pake serve user sehari-hari tiba-tiba nge-break karena ada dependency yang udah enggak relevan lagi. Kan kita juga day-to-day nya ngerjain fitur dan enggak ngecekin si dependencies ini.

Jangan sampe kejadian tahun 2016 terulang lagi, dimana library bernama left-pad tiba-tiba di-unpublish sama developernya terus bikin dunia Javascript seantero jagat mati total.

https://www.theverge.com/2016/3/24/11300840/how-an-irate-developer-briefly-broke-javascript

Weekly downloads specify the popularity

Weekly download juga bisa jadi faktor penting dalam menentukan library, karena weekly download yang banyak menandakan banyak user/developer yang percaya sama library ini, sehingga menandakan library ini cukup populer di kalangan developer.

Kenapa penting memilih library yang populer instead of indie? Karena library yang populer akan berbanding lurus dengan community support-nya. Sehingga ketika kamu punya issue, kamu akan merasa lebih aman karena pasti ada yang akan menjawab atau pasti ada yang pernah mengalami.

Your answer will be one Google Search away~

Issues and pull request count are your friend

Masih nyambung dengan popularitas sebuah library, semakin populer tentu sebuah library semakin banyak yang memperhatikan dan sama-sama ikut mempertahankan lifetime dari library tersebut. Hal ini akan ditunjukkan dengan kenaikan angka dari issues & pull request .

Issues ini enggak melulu yang buruk-buruk, bukan berarti library yang kita pake akan bermasalah kalo angkanya tinggi. Justru kalo kita mau spare waktu sedikit lebih banyak untuk ngeliat issues yang ada di library tersebut, kita justru malah tau, library ini kedepannya mau dibawa kemana dan gimana; apa hal-hal yang kemungkinan akan disupport di masa yang akan datang; apa aja limitation library itu; dll.

Jadi nggak usah takut sama angka issues yang tinggi, etapi issue yang tinggi perlu diikuti sama pull-request yang tinggi pula, karena ini artinya member komunitasnya mau berkontribusi untuk improve library ini. Kalo PR-nya kosongan, issuenya tinggi, artinya librarynya udah enggak ada yang nggubris. 😀

Unpacked size will affect your bundle size

Ini sangat perlu diperhatikan oleh frontend developer, terutama jika aplikasinya dipakai oleh user/customer dan bukan internal applications. Unpacked size dari sebuah library akan mempengaruhi seberapa besar bundle size dari aplikasimu.

Meskipun di teknologi sekarang sudah bisa kita akalin dengan adanya tree-shaking, lazy loading, dynamic import, dll, tapi akan jauh lebih baik memilih library yang punya size yang lebih kecil. Jadi tanpa melakukan optimization tadi, bundle size aplikasi kita tetap akan se-minimum mungkin.

Last publish will define your future fate

Last publish ini seperti namanya, kapan si latest version dari library ini dipublish. Saya biasanya akan memilih yang lebih muda alias yang lebih baru, karena dengan begitu teknologi yang dipakai kemungkinan lebih relevan dengan perkembangan saat ini, sehingga librarynya bisa lebih cepat, lebih performant, lebih optimized.

Tapi jika kamu tipikal orang yang lebih prefer yang lebih lama karena lebih battle-tested (enggak perlu dipublish lagi aja udah banyak yang pake kok), itu juga boleh. Yang penting jangan sampe terlalu jauh misal 1.5 tahun yang lalu last publishnya, itu bukan battle-tested, itumah otw deprecated.

Last but not least, the trending library might not be the best option, the rising star is

Ini agak berbeda approachnya, jadi kita enggak melihat di web npmjs.com tapi kita melihat di npmtrends

Kalo membaca penjelasan saya kan kita bisa simpulkan bahwa “oh berarti library yang populer ini yang paling baik buat saya ya”. Jawaban saya “ya belum tentu juga”

Kalo kita lihat redux ini merupakan state management library yang masih sangat populer di React, tapi setelah hands-on zustand , saya akan merekomendasikan zustand dibanding redux kepada temen-temen frontend saya yang lagi belajar atau lagi mempertimbangkan library state management yang baru.

Karena zustand punya approach yang lebih baru, lebih mudah digunakan dan disetup dibandingkan redux yang meskipun sekarang disupport sama redux-toolkit menurut saya tetap masih ribet penggunaannya.

Begitu teman-teman kurang lebihnya, mungkin masih ada banyak lagi pertimbangan lainnya, tapi baseline saya untuk memilih library biasanya itu sih.

Ternyata cukup banyak variable yang bisa kita pertimbangkan ya dalam memilih library di aplikasi/project kita. Hehe, semoga cerita kali ini bisa menambah insight buat temen-temen terutama frontend developer sehingga codebase yang sedang kamu kerjakan lebih maintainable dan sustainable.

Have a great day!

Choosing Your Frontend Library was originally published in Bahas Javascript on Medium, where people are continuing the conversation by highlighting and responding to this story.

Di dunia frontend development, perkembangan framework sungguh sesuatu yang jauh lebih cepat daripada perubahan topik pembahasan di sosial media. Silir berganti, baru baca framework A eh udah muncul framework B.

Di satu sisi ini merupakan hal yang menarik karena berarti banyak orang yang ada di komunitas frontend development sehingga bisa dibilang belajar frontend development di tahun ini masih relevan dengan kebutuhan industri. Tapi di sisi yang lain, perkembangan yang secepat ini bisa bikin banyak dari kita kecapekan sendiri ngikutinnya alias burnout.

Maka dari itu kita harus pandai pilah pilih apa yang harus dipelajari, ingat pandai pilah-pilih lo ya, bukan berarti enggak mau belajar. That’s two different things. Supaya kita belajarnya itu mampu menambah value kita ke depannya, meskipun tidak ada namanya belajar yang sia-sia, namun alangkah baiknya belajar yang memang bisa dapat hasil segera, ya to.

So here are a few tips from mehhh on how to start on a new framework, ceilah… Kita akan mulai dari non-technical (decision makingnya) dan baru masuk ke technical.

The non-technicals

Kebutuhan industri

Seperti yang saya mention di atas, belajar itu boleh, justru malah harus banget. Tapi misalnya untuk seorang frontend developer di level junior atau intermediate, alangkah baiknya untuk belajar framework yang memang sedang ramai di industri. Jadi misal nanti sudah lumayan pede dengan skillnya, bisa dijadikan value tambahan di company sendiri atau di calon company baru untuk meningkatkan taraf hidup. Taraf hidup jare~

Ya soalnya eman-eman, misal ada framework X muncul, ngehype di Twitter, tapi di industri belum terlalu urgent untuk di adaptasi. Yaaa meskipun a good thing untuk belajar framework tsb, kalo pandanganku sih tetep mendingan kalo mau explore coba yang emang industrinya lagi rame. Sehingga kita enggak perlu nyari “kolam” nya lagi ketika sudah cukup skillful. Tinggal pilih aja kolamnya.

Misal udah biasa pake React, yaa coba belajar ke Vue atau Svelte dulu, baru Remix. Gitu gitu lah~

Support komunitas

Karena kita sebagai developer di Indonesia belum sepenuhnya menjadi kreator di industri per-frontend-an, kita sejatinya adalah consumer at the same time. Nah, namanya sebuah produk yang dikembangkan oleh manusia yang sumbernya salah dan dusta, pasti produk itu juga tidak sempurna. Barangkali ada bumbu ghibah saat developnya, bukan deng.

Setiap product pasti punya flaw nya sendiri-sendiri, menurut consumernya yang mana ini adalah kita, frontend developer. Maka dari itu… support komunitas yang kuat sangatlah penting dalam pertimbangan memilih framework yang akan dipelajari.

Dulu semasa saya masih sering ikut untuk jadi facilitator, saya dikasih tau bahwa “Problem yang kamu temui saat ngoding itu pasti orang lain di luar sana sudah pernah menemui juga”. Makanya dengan adanya komunitas yang besar dan baik, insyaAllah ketika kita ngoding dan nemu issue, the solution is one Google search away (atau ya one ChatGPT prompt away, terserah si). Jadi ya gitu, adanya komunitas juga bisa menjadi pelipur lara bahwa banyak developer yang lain stumble dengan issue kita lo, jadi kawan sepernasiban lah ibaratnya.

Enggak asik banget kalo misalnya udahlah belajar teknologi baru, nemu issue, eh enggak ada solusinya. (Kalo kamu udah level pro dan bisa bikin proposal untuk solve issuenya, kamu pengecualian ya bang jago, saya nggak lagi ngomong sama kamu -_-)

The technicals

Dua poin di atas tadi adalah biasanya pertimbangan saya untuk mempelajari teknologi baru, utamanya framework. Nah untuk beberapa poin di bawah ini akan jadi pertimbangan yang biasa saya pikirkan saat belajar framework baru. Jadi katakanlah kamu sudah mantep memilih sebuah framework untuk dipelajari, here are the key points I usually take a look at:

Writing Component

Hal paling basic adalah gimana sih cara kita bikin component-component di framework itu. Apakah pake JSX atau pake HTML biasa, atau gimana. Terus misal kita udah punya component itu kalo mau dipake penulisannya gimana a.k.a splitting component nya gimana. Yakali mau ditulis semua di satu file.

Interactivitynya

Interactivity atau reactivity kayaknya sudah jadi fitur wajib sebuah framework frontend, karena kan ya kita ingin dapat feedback langsung ketika ada perubahan data. Kalo enggak ada interactivity/reactivity ya ngapain pake framework, pake HTML5 basic aja lah kalo begitchu~

Biasanya reactivity diwakili dengan penggunaan State dan Data binding ke componentnya. Nah ini perlu dilihat gimana penggunaan local state dan data binding di suatu framework.

Misal di React mah kita biasa

function SomeComponent() {
  const [count, setCount] = useState<number>(0);

  return (
    <>
      <button 
         onClick={() => { setCount(prev => prev + 1) }}
      >
        Tambah bro {count}
      </button>
    </>
  )
}

Sedangkan di Svelte dia bakal kaya gini

<script>
 let count = 0;

 function increment() {
  count += 1;
 }
</script>

<button on:click={increment}>
 Tambah bro {count}
</button>

Nah sebenernya kan keduanya sama, tapi penulisannya aja yang beda.

Populate datanya

Setelah kita tau gimana komponen itu reactive terhadap perubahan data, selanjutnya kita juga perlu tau gimana data itu bisa dishare ke component yang lain. Kan enggak lucu masak datanya cuma bisa dipake di component Button doang, atau masak kita harus bikin suatu component kompleks jadi satu.

Makanya itu kita perlu tau misal kita mau passing data ke child componentnya itu gimana, apakah props drilling kah atau apakah, gitu. Terus kalo kita ketemu case kita harus populate data ke 3 level di bawahnya itu harus gimana, kan enggak mungkin kita props drill sampe ke bawah-bawah.

Kembali lagi, misal di React

// Case untuk 1 level
function ParenComponent {
  return (
    <ChildComponent data={data} />
  );
}

// Case untuk level yang banyak, kita bisa pake React Context API
function SomeLowLevelComponent() {
  const data = useContext(ParentContext);

  return (
    <div>{data}</div>
  );
}

Sedangkan di Svelte mungkin kurleb kaya gini

# Case 1 level
<script>
  import ChildComponent from './Child.svelte'
</scrript>

<ChildComponent data={data} />

# Case multiple level
<script>
  let value

  value.subscribe(val => {
    value = val
  })
</scrript>

<LowLevelComponent data={value} />

Nah ini kita harus clear karena data-data ini kan krusial untuk mendukung interactivitynya, jangan sampe datanya enggak bisa diintegrasikan ke component yang lain. Ya kalo begitu buat apa ya to, mending pake jQuery aja atau malah enggak usah pake framework aja. Pake vanilla JS dan mainan innerHTML nya aja.

Another thing to note adalah… support data store nya. Misal kaya di React selain punya Context API, kita bisa integrate data store kita pake Redux, zustand, jotai, dll. Enggak semua framework perlu integrasi third-party ini, tapi kalo ada dan bisa ini juga bisa dikulik. Barangkali bisa bikin management data kita lebih rapi secara flow maupun codingan.

Routingnya

Part terakhir yang saya lihat ketika saya udah tau gimana cara saya buat manage component, data dan interactivitinya, adalah gimana kita bikin routingnya. Again… enggak semua hal bisa ditaruh dalam satu halaman. Bahkan mostly untuk real-world application kita perlu memisahkan menjadi beberapa routes.

Karena dengan begitu kita bisa lebih mudah untuk track historicalnya user, kemudian memudahkan logic yang kompleks atau logic untuk render-render component maupun data fetchingnya.

Di React sendiri kalau kita pake standalone, kita bisa pake react router, kalo kita pake framework Next JS kita malah udah bisa pake folder-based. Nah ini juga perlu dicek di framework yang mau kamu pelajari baik secara standalone itu gimana terus kalau misalnya lebih advanced gimana.

Kenapa perlu tau keduanya, barangkali suatu saat kamu enggak perlu fitur yang terlalu advance, biar tidak overkill ya abangku.

(Bonus) UI and Testing environments

Ini bonus, tapi kayaknya ya tetep aja cukup penting. Tidak lain dan tidak bukan adalah gimana kita ngestyling componentnya karena tidak munqin user mau dikasih tampilan basic HTML. Styling ini aku biasanya cari tahu alternatifnya:

• Apakah pakai CSS file terus diimport
• Apakah bisa di styling langsung componentnya
• Apakah bisa pake library styling components (misalnya styled-components)
• Support UI library/UI kit di luarannya itu gimana, mudah dan lengkap enggaknya

Kalo semua aspek di UI ini terjawab, biasanya saya udah ready to go untuk coba cari use case untuk diimplement pake framework baru ini.

Bonus tambahan, jelas kita perlu juga tau gimana kita kalo mau setup dan jalanin testing di aplikasi kita. Supaya apa? Supaya value kita juga bertambah, semua orang mungkin bisa ngoding, tapi belum tentu semua orang bisa bikin testing yang baik.

Maka dari itu… step terakhir yang kadang saya enggak lewatkan (seringnya dilewatkan soalnya), gimana unit testnya, integration testnya, kalo bisa juga masuk ke end-to-end testingnya tipis-tipis.

Dengan begitu setelah belajar framework baru, kamu bisa semakin las les sat set untuk tau arahnya gimana. Enggak cuma yang “cobain ah, terus ngapain ya ini” dan setelahnya bisa kamu jadikan bahan show-off untuk meningkatkan value kamu sendiri.

Well, it’s quite a long story for me too, semoga kamu membaca sampai akhir dan menikmati tulisan saya kali ini. Have a nice day everibadee!

New Framework, Where to Start? was originally published in Bahas Javascript on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kadang sebagai developer kita pengen gitu bantuin komunitas kita untuk “modernize” aplikasinya biar informasinya lebih accessible dan readable. Tapi kepentok dengan issue kalo datanya sekarang ini masih disimpen di excel atau google sheets.

Mau dipindah ke RDBMS kok males (apalagi kalo banyak), kalo enggak dipindah gimana cara web app kita bisa dapet datanya.

Saya juga kemarin nemu issue begitu, salah satu komunitas saya mau bikin sebuah web untuk yaa semacam portal informasi sekaligus biar anggota bisa ngecek apakah membershipnya sudah diapprove atau belum. Tapi masalahnya semua datanya di Google Sheets, masalah yang lain jumlah membernya udah di angka 8000-an, jadi kan mau bikin MySQL (eh MariaDB) ya males, kalo mau langsung pake gimana caranya?

Setelah saya kulik lagi, ternyata web yang ingin dibuat ini enggak ada CRUD nya, jadi saya “cuma” butuh bisa baca/read aja data dari si Google Sheets.

Okay, jadi begini caranya, sakjane super simple…

Pertama kita perlu siapkan table dari Google Sheets nya, pastikan row nomor 1 berisi label dari data-data kita

Inget ya, harus banget, row pertama adalah row labelnya. Jika kita sudah memastikan kalo bentuknya kurang lebih kaya gitu, langkah selanjutnya kita menuju ke File -> Share -> Publish to Web

Setelahnya bakal muncul dialog/modal, untuk kolom pilihan yang sebelah kiri, saya biasanya cuma pilih Sheet instead of Entire Document , untuk yang pilihan sebelah kanan kita pilih publish sebagai Comma Separated Value (CSV) .

Jadi… sederhananya kita akan akses datanya melalui data CSV, ketika datanya sudah CSV kita selanjutnya bisa lakukan fetching data dengan library apapun bisa pake axios atau fetch .

The preparations are done… now let’s fetch the datas…. 🥁

Untuk case ini saya pake axios, kalau ada yang pake yang lain, bisa menyesuaikan eaps…

Sebelumnya kita perlu bikin parser CSV dulu, ini bisa pake library csv2json, tapi saya pake function sendiri supaya bisa dipake di client side maupun ketika di server side.

// @ts-ignore
export function parseCSV(csvText) {
  const rows = csvText.split(/\r?\n/); // Split CSV text into rows, handling '\r' characters
  const headers = rows[0].split(","); // Extract headers (assumes the first row is the header row)
  const data = []; // Initialize an array to store parsed data
  for (let i = 1; i < rows.length; i++) {
    const rowData = rows[i].split(","); // Split the row, handling '\r' characters
    const rowObject = {};
    for (let j = 0; j < headers.length; j++) {
      // @ts-ignore
      rowObject[headers[j]] = rowData[j];
    }
    data.push(rowObject);
  }
  return data;
}

Then… kita fetch aja datanya

const GOOGLE_SHEETS_LINK = "your link here";

const fetchData = async () => {
  const response = await axios.get(GOOGLE_SHEETS_LINK);

  const { data } = response; // this will return data csv

  if (data) {
    return parseCSV(data); // parse csv to array of object
  }

  return [];
}

Dari fetch di atas kita akan dapat response seperti ini yang selanjutnya bisa kita consume di component kita

[
  { label1: "data", label2: "data" } // dst
]

Done, it’s as simple as that!

Dengan begini kita bisa consume data dari Google Sheets ke component kita. Apalagi ketika kita melakukan update pada sheets/table kita tadi, secara otomatis akan reflect ke API yang kita consume, jadi enggak perlu khawatir harus republish-republish.

But still… ini hanya quick temporary measurement dan untuk have fun aja. Kalau temen-temen butuh fitur yang lebih lengkap dan lebih advance terkait data management ini, saya tetep sarankan untuk dimigrate pakai RDBMS yang lebih proper, sekalipun bukan MySQL.

That’s it, have a good day everyone!

Using Google Sheets as Your Database was originally published in Bahas Javascript on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dalam men-develop aplikasi terutama yang berbasis React JS, tentu kita seringkali dihadapkan dengan case-case yang mengharuskan kita untuk mengcustom suatu component atau kalau di post ini saya bahasakan dengan nge-styling component. Ya pasti karena kalo tidak distyling webnya akan jadi seperti website di era sebelum CSS muncul.

Back then ketika framework javascript belum populer, salah satu go-to library yang saya pakai ya tentu saja UI Library kita semua yang tak lain dan tak bukan adalah bootstrap. Di saat itu bootstrap sudah canggih banget lho, kita bisa bikin element/component macam-macam dengan cukup mudah, sudah ada implementasinya yang disematkan di dokumentasinya tinggal di copas aja, terus beres deh terpasang di web kita. Jadilah web kita canteek, ya to.

Atau ada juga si paling radikal, yang membuat stylingnya sendiri full pake CSS, ini sih sudah bisa dipanggil suhu kala itu.

Nah di zaman yang semakin berkembang, akhirnya trend website yang sebelumnya dibuild pure dengan HTML+CSS+imbuhan JS dikit kini berkiblat ke Javascript-based yang dipionir oleh tiga framework yang bertahan hingga sekarang yaitu React, Vue, dan Angular (meskipun kalo di Indonesia sepertinya jarang ya denger developer Angular). Kemudian trend untuk styling component pun juga agaknya cukup berubah. Meskipun tetap masih ada juga yang implementasinya mirip-mirip.

Contohnya dengan naiknya TailwindCSS yang masih berbasis class name untuk stylingnya. Dan cara ini juga masih dipakai di development React hingga sekarang kok, dengan membuat file CSS dan styling disitu. Which is fine, once again, as long as it works and it’s on production, you have nothing to worry about.

Tapi… untuk saya sendiri, saya lebih suka beberapa cara berikut untuk styling component saya, alias go-to saya ketika saya diharuskan untuk styling components.

Ohiya, sebagai disclaimer saya lebih suka styling component dengan bikin sebuah component (apa ya ini namanya) pokoknya bukan pakai className gitu lah.

Styled components (the pure one)

Sejak saya belajar bikin web dengan tanpa framework, saya itu memang lebih suka bikin styling sendiri instead of mengandalkan UI library. Karena dengan begitu ada ke-khas-an dari design web saya dan bisa saya achieve tanpa perlu banyak adjustment, berikan aku file CSS maka akan kuguncang landing page.

Maka dari itu cara saya styling component saat ini masih jatuh ke cara CSS-in-JS, lebih spesifik adalah styled-components . Selain library styled-components sebenernya ada library lain seperti emotion yang sakjane kurang lebih implementasinya sama, tapi saya enggak pernah nyobain di project yang skalanya cukup besar jadi tidak bisa berkata banyak.

// Instead of 
<SomeComponent className="abc def gih" />

// Saya lebih suka
const SomeStyledComponent = styled.div`
  // your style here
`;


<SomeStyledComponent />

Ohiya, styled components juga bisa buat ngestyling component-component UI dari library lain, jadi misal kita ada mau bikin custom DatePicker, kita bisa comot DatePicker yang udah ada, terus kita ubah stylenya pake doi.

export const StyledDatePicker = styled(DatePicker)`
  .some-class-to-style {
    width: 100px;
    // your styles
  }
`;

Styled components with styled system (xstyled, styled-system, etc)

Berangkat dari styled-components selanjutnya kita bisa level-up the game dengan mengintegrasikan dengan library lain untuk bikin design system yang lebih mudah.

Di daftar rekomendasi saya ada @xstyled/styled-components dan styled-system . Ini nih yang saya bikin suka sama styled-components , karena selain bisa dicustom sendiri kita mau bikin component apa, kita juga bisa bikin dia lebih mudah untuk dipakai di codenya.

// Before styled system
const StyledCompo = styled.div`
  margin: 32px;
  font-family: "Proxima Nova", sans, monospace;
`;

import styled from "@xstyled/styled-components";
// After styled system
const StyledCompo = styled.div`
  margin: 3; // ini nanti ada confignya 3 itu apa
  font-family: regular; // ini juga
`;

Selain itu dengan adanya si styled system ini kita bisa bikin commons components yang kita bisa pake semau kita nantinya di component-component kita.

return (
  <Flex mb={20} gap={8}>
    <Text family="bold" fontSize={2}>Lorem ipsum</Text>
  </Flex>
);

Jadi misal ketemu cuma perlu styling dikit, kita enggak perlu bikin component baru, atau kita harus nge-include si props tambahan ke styled component kita secara manual, atau kita perlu inject di prop style={{ ... }} nya.

Stitches x Radix UI

Ini saya baru nemu kayaknya setelah kerja di tempat kerja yang sekarang ketika ngerjain project baru gitu. Kebetulan ada temen yang memang suka explore codingan dan sharing terkait ini. Stitches ini kurang lebih sama dengan styled-components dan emotion , sama-sama CSS-in-JS, keunggulannya dia ini jauh lebih lightweight dengan hanya ~6KB dan support Server-Side Rendering (SSR). Jadi ini salah satu solusi yang menyenangkan untuk para frontend yang projectnya pake SSR.

// Cara pakenya
import { styled } from '@stitches/react';

const Button = styled('button', {
  backgroundColor: 'gainsboro',
  borderRadius: '9999px',
  fontSize: '13px',
  padding: '10px 15px',
  '&:hover': {
    backgroundColor: 'lightgray',
  },
});

const SomeComponent = () => {
  return (
    <Button />
  );
}

Selain itu pros-nya, dia enggak perlu banyak diconfig, alias plug ‘n play, pasang langsung bisa dipake. Juga di stitches ini kita bisa bikin styled system secara langsung tanpa perlu ada library lain buat nge-bridge nya. Wow, semua hal tadi dilakukan oleh library dengan ukuran <10KB.

Cons-nya, saat ini masih support React JS aja. 😅

Selain stitches yang udah oke, lebih oke lagi dicombine pake Radix UI, dimana di dalamnya sudah ada component-component yang siap pake kaya Dialog, Card, Tooltip, etc . Di Radix sendiri ada 2 cara pake, mau dipake/di-install satu-per-satu alias ala carte dengan cara

npm install @radix-ui/react-dialog
npm install @radix-ui/react-dropdown-menu
npm install @radix-ui/react-tooltip

atau kita juga bisa langsung install sepaket semuanya dengan cara

npm install @radix-ui/themes 

dengan begitu semua component dari Radix bisa kita pake langsung dengan import sesuai yang kita butuhkan. Kekurangannya ya kalo ini ada component yang sebenernya enggak kita pake, ini akan jadi beban bundle kita. Hehe

Syudah, secara garis besar sebenernya itu cara saya styling component untuk project freelance, kerjaan, maupun project iseng. Selanjutnya biasanya saya combine dengan library lain misal styled-components sama ANTD, atau sama Evergreen UI (ini bagus, ringan, tapi kurang populer nampaknya), atau sama Chakra UI, ya gitu-gitu lah, dipadu padankan satu sama lain.

Alasan saya enggak pake library yang berbasis class name lagi kaya bootstrap maupun Tailwind adalah karena saya males ngapalin nama class CSS nya, belum lagi ada ukurannya yang udah didefine oleh design system mereka 😵. Saya lebih suka dia jadi props karena bisa di-autocomplete kalo kita kebetulan juga pake Typescript.

Tapi sekali lagi saya mengingatkan, tidak ada silver bullet dalam men-develop aplikasi web (React), yang penting kita nyaman developnya, mudah dipahami oleh developer lain, mudah untuk dimaintain, dan udah launch ke production (dan nge-gaji kamu), it’s fine~. Kalo suatu saat kamu mau ubah caramu styling components mirip-mirip kaya saya, it’s also fine~

Let’s have a fun time developing apps. See you!

Styling your Components was originally published in Bahas Javascript on Medium, where people are continuing the conversation by highlighting and responding to this story.

Halo, sepertinya sudah sangat lama sekali saya buka Medium. Bahkan saya enggak inget apa yang terakhir kali saya tulis di platform ini. Kali ini saya kembali, wasyah

Di kesempatan kali ini saya ingin nulis terkait hal yang saya pelajari lebih dalam kemarin, meskipun sebenernya selama 5 tahun karir professional saya ini, saya udah pake. Tapi baru akhirnya saya paham dan bisa bener-bener merasa lebih pede untuk implement di code saya. Dan hal yang saya pelajari lagi tak lain dan tak bukan adalah setting up ESLint-Prettier di VSCode.

Perlu diketahui lagi, biar saya enggak dianggap noob banget, saya tuh udah pake eslint dari dulu, sudah paham tentang rules-rulesnya juga, tapi nge-integrate antara eslint, prettier, dan VSCode seamlessly itu perkara lain. Hahaha

Mari langsung kita masuk ke topiknya saja deh ya….

Sebelumnya perlu diketahui secara singkat kalo prettier itu sebuah code formatter, yang mana tool ini membantu supaya code kita lebih enak dipandang. Sedangkan eslint itu sendiri linter, yang bertugas untuk memastikan code yang kita tulis itu sesuai standard yang umum dipakai dan penulisan code kita ini efektif.

Jadi meskipun keduanya sering dijadikan sebuah combo maut, keduanya punya fungsi yang berbeda.

Oke, sekarang beneran kita masuk ke pembahasan utama. Untuk meng-setup ESLint-Prettier di VSCode, kita perlu melakukan beberapa hal ini:

• Setting up ESLint
• Setting up Prettier
• Integrate dengan VSCode

Prerequisites

• VSCode dengan extension ESLint dan Prettier

Setting up your ESLint

Untuk setup ESLint sebenernya banyak caranya, kita bisa melakukan dengan cara manual, init melalui npm, maupun langsung dengan memilih config yang populer. Tapi jalan yang saya pilih adalah dengan menggunakan npm init

npm init @eslint/config

Dengan code ini kita akan disuguhi dengan beberapa pertanyaan kaya gimana ESLintnya mau dipake, gimana behavior impor/export codebase kita, framework apa yang kita pake dan mau pake popular style atau enggak. Kita bisa pilih menyesuaikan kebutuhan masing-masing codebase kita. No silver bullet

Setelahnya kita akan dikasih list library yang perlu diinstall dan tinggal pilih Yes , kemudian tunggu aja. Voila, ESLint sudah berhasil terinstall di codebase.

Setelah eslint ini berhasil terinstall dia akan melakukan scan terhadap codebase kita sesuai rules-rules yang diberikan di config filenya yang biasanya namanya eslintrc.* atau eslint.config.* untuk file config yang baru.

Step 1 Done

Setting-up the Prettier

Langkah selanjutnya yaitu menginstall prettier ke code kita supaya codenya jadi lebih rapi.

Untuk step ini biasanya juga ada beberapa cara, cara yang paling umum digunakan adalah menginstall Prettier ke VSCode kita dan menambahkan rules-rules ke file confignya .prettierrc .

Tapi untuk hal ini catch nya biasanya ada beberapa rules yang conflict satu sama lain antara ESLint yang sudah kita define dengan si prettier tadi. Maka di post kali ini saya menggunakan approach yang berbeda yaitu dengan menggunakan eslint-plugin-prettier sehingga antara rules yang telah kita apply ke file eslint config tidak conflict dengan prettier.

Mula-mula kita install dulu packagenya

npm install --save-dev eslint-plugin-prettier eslint-config-prettier
npm install --save-dev --save-exact prettier

Kemudian kita tambahkan prettier ke config eslint yang telah ter-generate tadi

// File: eslintrc.js
{
  // ...
  // tempatkan prettier di paling belakang untuk override 
  // styling dari config/plugin yang lain
  extends: [..., "plugin:prettier/recommended"],
  
  // ...
  rules: {
    "prettier/prettier": [
      "error", 
      {
        // kalau mau tambah custom config
      }
    ]
  }
}

Dengan menambahkan ke extends sebenernya sudah cukup untuk implement prettier ke code kita, tapi kalau mau nambahin rules yang lain bisa juga tambahin secara manual di bagian rules

Step 2 done

Setelah menginstall eslint dan prettier tadi, bukan berarti langsung usable, maksudnya code kita tidak akan secara otomatis di-fix ketika ada issue kecuali kita menambahkan script ke package.json untuk nge-lint code kita, misalnya:

"scripts": {
  // ...
  "lint": "eslint --quiet --fix"
}

Tapi tentu saja ini masih ribet kecuali kita integrate script ini dengan tools lain, kita harus run script nya secara manual biar code kita terdetect dan bisa difix. Yakali masak gitu, rugi dong

Maka dari itu kita masuk ke last step…

Integrate the tools with VSCode

Ini bagian yang sebenernya singkat banget, kita cuma perlu nambahin/ubah file config vscode kita menjadi:

{
  "editor.formatOnSave": true,
  "editor.formatOnPaste": true,
  "[javascript][javascriptreact][typescript][typescriptreact]": {
    "editor.formatOnSave": false
  },
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  }
}

Dari config di atas kita enggak pengen melakukan formatting ketika nge-save code dengan formatter biasa, tapi kita pengen nyuruh si eslint untuk ngefix code kita aja.

Oh iya, sekali lagi jangan lupa untuk install Prettier dan ESLint di VSCode nya ya.

Setelahnya, code kita sudah ready to go untuk diajak tempur.

—

Saya menggunakan approach ini karena seringkali saya ketika pake prettier dia conflict dengan si eslint jadi kadang malah eslint nya yang perlu mengalah atau malah saya harus kasih eslint ignore ke code saya, yang mana ini bukan best practice.

Tapi sekali lagi, approach ini bukanlah silver bullet untuk menginstall ESLint ke codebase kita, banyak cara lain dan as long as it works, it works. 😉

References:

• https://eslint.org/
• https://github.com/prettier/eslint-plugin-prettier
• https://github.com/wesbos/eslint-config-wesbos
• Insall ESlint by Wesbos

Setting Up Your ESLint was originally published in Bahas Javascript on Medium, where people are continuing the conversation by highlighting and responding to this story.

Sebenernya cerita semacam ini udah pasti banyak ditemui di luaran sana, bahkan saking banyaknya tinggal kita tulis keyword “best javascript framework” dan kita tinggal pilih aja salah satu artikel secara random. Saya juga sebenernya agak ragu untuk nge-publish cerita ini karena saya masih ngerasa pengalaman saya belum sebanyak itu untuk bisa ngebahas topik ini. Hmm… Mari kita buat a la saya cerita aja deh ya.

BTW udah lama saya enggak nulis gini… Prepare your tea and have a seat, everibadeee.

Secara umum, setahu saya ada tiga framework yang sampe sekarang masih jadi “the big 3” javascript framework, tentu seperti yang sudah kita duga, jQuery, heh bukan bukan, React, Vue, dan Angular. Banyak praktisi Javascript yang sebenernya kurang suka melakukan hal-hal kaya gini, membanding-bandingkan framework — kita sebut saja framework ya — Javascript yang satu dengan lainnya. Alasannya sederhana, karena sebenernya semuanya hampir-hampir sama, at least untuk sekarang ini, top framework Javascript punya fitur yang kurang lebih hampir sama, kemudahan yang sama, support dari komunitas yang cukup besar juga. Jadi daripada dibandingkan, lebih baik kalo penasaran ya tinggal dicoba aja gitu lo maksudnya.

React JS

Saya akan mulai dari framework yang paling familiar buat saya, React JS. Framework bikinan facebook yang saya mulai kenal di 2016 silam dan sejak 2018 saya pake sebagai daily “driver” saya. Sebenernya React ini kurang pas disebut framework, lebih tepat kalo disebut UI library. Alasannya sederhana karena semua hal lain seperti routing, global state management, dll, perlu library lain, ini kalau kasusnya kita pengin bikin aplikasi React yang full javascript. React juga bisa kita pasang layaknya library javascript lainnya dengan cukup tulis di bagian body HTML kita.

<script crossorigin src="https://unpkg.com/react@17/umd/react.production.min.js"></script>
<script crossorigin src="https://unpkg.com/react-dom@17/umd/react-dom.production.min.js"></script>

React punya komunitas yang besar banget di dunia, serta banyak library yang bisa dipake macem-macem di React, bahkan hampir semua library yang dulu kita pake di jQuery, kini udah ada wrappernya di React. React juga punya dua framework yang terkenal yaitu Next JS dan Gatsby JS.

React juga bisa kita tulis menggunakan Typescript, bisa dibilang bahasa pemrograman advancenya javascript yang kayaknya akhir-akhir ini lagi naik daun. Juga dilengkapi dengan salah satu library favorit saya bernama styled-components yang bikin kita styling component di React jauh lebih mudah.

Awalnya saya sih biasa aja sama styled-components saya nyoba bikin web dengan stack HTML+CSS, baru kerasa betapa saya take styled-components for granted.

Tapi masalahnya… Sebagai frontend developer yang lebih banyak main di React sendiri, saya bisa bilang learning curve React ini cukup nganu. Untuk web developer yang belum pernah nyobain library JS pasti akan kaget karena biasanya kita nulis script javascript di dalam body HTML, sedangkan React dengan JSX nya memutar balikkan persepsi kita dengan nulis tag HTML di dalam script javascript.

Selain terkait JSX, ada juga yang mungkin bisa bikin agak bingung yaitu implementasi class component, sepengalaman saya banyak temen-temen yang bingung dengan penggunaan class component di React. Ya meskipun sekarang udah ada juga fitur bernama hooks yang memudahkan bikin component pake function instead of a class. Katanya sih hooks bikin lebih clean, tapi saya sebagai penganut class component garis keras, sebenernya lebih suka class component, lebih gampang ditest pake Enzyme soalnya, hohoho.

Ohiya, karena masih populer, peluang kerja frontend developer yang bisa React ini masih terbuka sangat lebar kok, masih banyak perusahaan yang pake teknologi ini atau beralih ke teknologi ini.

Untuk junior level mungkin pengetahuan tentang vanilla javascript, React, Redux, hooks, udah cukup. Sedangkan untuk level yang lebih tinggi bisa explore terkait unit testing (Enzyme, Jest, React testing library), Typescript, framework (Next JS, Gatsby JS), state management selain Redux (Recoil JS, Context).

Vue

Vue JS (dibaca vyu je es) bisa dibilang framework yang naik daun dengan cepat 2–3 tahun terakhir ini. Framework yang diinisiasi oleh Mas Evan You ini menurut saya fiturnya yang paling mirip-mirip sama React JS, misalnya fitur virtual DOM nya, atau yang bisa dipasang sebagai CDN dengan menambahkan tag script di body HTML kita.

<script src="https://cdn.jsdelivr.net/npm/vue@2.6.12"></script>

Ohiya Vue juga bisa langsung dipasang di Laravel, kayaknya diantara yang lain Vue ini satu-satunya yang saya temui bisa diembed langsung ke framework PHP. Bahkan jadi recommended javascript library buat Laravel kalo enggak salah.

Vue sendiri udah ngalain jumlah star nya React di Github, jadi support komunitas di Vue ini juga besar banget di dunia, banyak banget juga library untuk support kita bikin aplikasi Vue. Saya sejujurnya belum terlalu deep belajar Vue, jadi enggak begitu tau apakah Vue punya framework semacam Next JS atau Gatsby JS gitu. Tapi yang pasti library untuk styling component udah support Vue, meskipun implementasinya cukup beda dibandingkan ketika diimplementasi di React.

Vue juga punya keunggulan sendiri terkait learning curve, menurut saya learning curve Vue cukup tolerable. Karena untuk ngebikin componentnya masih hampir-hampir sama ketika kita develop web dengan stack HTML+CSS, orang-orang yang masih awam dengan library javascript yang belajar Vue akan lebih gampang ngeh-nya dibanding belajar React. It’s really a good point anyway.

Saya enggak begitu bisa bahas lebih jauh terkait Vue, karena cuma pernah nyoba sekali dua kali, itu pun mindset saya masih rekat sama React, jadi belajarnya juga enggak optimal.

Tenang, meskipun begitu saya cukup tau kok kalo perusahaan yang minat untuk pake Vue ini juga makin banyak, malah saya dulu ketika proses nyari kerja lebih banyak nemu requirement yang membutuhkan frontend developer yang pake Vue dibandingkan React.

Angular

Nah ini yang saya paling enggak bisa bahas, framework javascript yang bisa dibilang karirnya paling lama. Dibacking oleh perusahaan yang pasti kita udah familiar, tidak lain dan tidak bukan, Google. Angular ini bisa dibilang framework yang beneran framework, karena ketika kita install, kita akan dikasih segelondong lengkap, se routing-routingnya, tinggal diconfig aja.

Di awal kemunculannya Angular (AngularJS) masih dengan cara binding data ke HTML tag atau bikin component dengan HTML tag, yang saya rasa cara ini diadopsi oleh Vue JS. Tapi sejak muncul Angular, implementasinya bener-bener berubah, dan saya cuma berkesempatan untuk nyobain AngularJS.

Berbeda dengan dua library sebelumnya yang bisa kita install cukup dengan CDN, saya nyari tau di dokumentasi resmi Angular ini enggak nemu instalasi lewat CDN, jadi kayaknya emang harus full javascript gitu.

Angular sendiri udah make implementasi Typescript, jadi ini jadi drawback tersendiri ketika kita mau belajar Angular tapi pengetahuan javascript kita masih basic. Kita musti belajar proses MVC yang ada di Angular serta Typescript itu sendiri.

Dulu AngularJS punya masalah terkait performa yang bakal lambat banget ketika codebase kita makin besar, jane ya wajar kalo makin berat, tapi enggak tolerable gitu lo, jadi sejak berevolusi jadi Angular banyak issue terkait performa yang diperbaiki sama tim pengembangnya.

Saya enggak bisa bahas lebih lanjut, karena blas belum pernah nyobain framework ini. Terkait kesempatan kerja juga saya enggak begitu tau, setau saya perusahaan di Indonesia jarang yang pakai Angular, tapi banyak perusahaan di luar negeri yang pakai Angular, jadi mungkin kesempatannya justru lebih terbuka lebar kalau kita apply di perusahaan luar negeri.

Rising Star: Svelte

Svelte juga jadi hot topic di tahun lalu, library yang digadang-gadang punya performa jauh lebih baik dari ketiga framework Javascript di atas, learning curve yang lebih mudah karena implementasinya hampir-hampir sama kaya Vue yang main-main di tag HTML dan tanpa adanya Virtual DOM. Menarik!

Udah banyak perusahaan yang pake teknologi ini kaya Gojek, Tokopedia, GoDaddy, Rakuten, dll.

Saya sempet nyobain Svelte ini sekilas sih, dan emang asyik main-main Svelte ini juga potensinya besar banget. Karena Svelte yang newcomer ini tentu komunitas dan supportnya masih belum sebesar “the big 3”, tapi saya yakin Svelte juga akan segera punya komunitas yang besar.

Mari kita lihat apakah framework satu ini bisa menggeser trend top javascript framework.

Recap

Sejatinya, saya enggak bisa bilang mana framework terbaik, alasan pertama karena saya belum nyobain semuanya jadi masih kurang pengalaman; alasan kedua semua framework ini punya pasar sendiri dan memenuhi kebutuhan masing-masing, selama kebutuhan kita untuk develop web app terpenuhi dengan salah satu framework di atas yaudah, cukup aja gitu; alasan ketiga, familiarity dan preference, preferensi orang-orang untuk nulis kode serta rasa familiarnya bener-bener berbeda, orang yang lebih suka bisa dipisah-pisah dan bisa diimport lebih gampang mungkin memilih React, orang yang suka main di tag-tag HTML mungkin akan memilih Vue atau Svelte, orang yang suka implementasi Typescript mungkin akan pilih Angular atau React.

Menurut saya cobain aja semuanya dulu, terus pilih satu yang paling cocok, dalami sampe paham, baru nanti pindah. Karena untuk belajar framework di atas sebenernya kamu cukup punya fundamental javascript yang cukup kok, selebihnya tinggal penyesuaian nulis kodenya aja.

That’s it, selamat belajar. Have a great day.

Library/Framework JS Terbaik…? was originally published in Bahas Javascript on Medium, where people are continuing the conversation by highlighting and responding to this story.

Fitur-fitur keren Javascript di tahun 2020 yang aku temukan

Javascript adalah bahasa pemrograman yang berkembang dengan sangat cepat, dengan komunitasnya yang sangat besar, kemudahan untuk contribute di berbagai library. Bahkan kasarannya, kita meleng sehari aja bisa-bisa udah ketinggalan banyak update terkait Javascript. Emang segila itu perkembangan Javascript sekarang.

Sejak munculnya ECMAScript 2015 atau yang dikenal dengan ES6, aku merasa hal itu jadi game changer buat Javascript. Dari kemunculannya muncul banyak library untuk support Javascript di web browser, misalnya transpiler kaya Babel. Muncul juga berbagai library yang dibilang memudahkan pengembangan web kaya Webpack atau RollUp sebagai module bundler; atau PostCSS sebagai tool buat ngetransform CSS kita yang bisa menggantikan Sass yang merupakan Gem dari Ruby, ada juga Grunt dan Gulp yang sempat populer sebagai task runner, dan masih banyak lagi perkembangannya sampe sekarang.

Di tengah berbagai fitur dan perkembangan yang ada sejak 5 tahun lalu, di tahun kemarin lewat beberapa referensi lewat temen, twitter, atau baca-baca sendiri, aku nemu fitur-fitur keren Javascript yang bener-bener bikin nge-develop web jadi makin gampang.

Optional Chaining

Sebagai developer pasti sering banget berinteraksi sama data dengan tipe object, mau itu object beneran atau array. Baik dari logic codingan kita sendiri maupun data yang diterima dari tim backend.

Dari snippet di atas, ketika kita mau akses data address.location kita bisa langsung dengan tuliskan data.address.location kan?

// abnormal condition
let data = null;

console.log(data.address.location.pluscode); // error, can break the app

// Uncaught TypeError: Cannot read property 'address' of null

Tapi gimana kalo misal value dari data itu bisa null atau undefined ? Tentu kita perlu kasih handler supaya aplikasi kita enggak nge-break, karena kalo enggak dikasih handle kita bakal mencoba ngakses property dari sebuah value yang undefined/null tadi.

if (data && data.address && data.address.location && data.address.location.pluscode) {
  console.log(data.address.location.pluscode);
} // ampun deh 

Ampun deh, bayangin kita cuma butuh satu petil data tapi handler nya bisa jadi panjang gini, belum lagi misal objectnya nested lebih dalam lagi, bisa panjang banget dan code kita jadi enggak readable.

Dengan adanya optional chaining, kita bisa akses data-data yang sekiranya bakal nullable tapi enggak bakal bikin aplikasi kita nge-break atau nge return error. Karena ketika akses dan ketemu error, akan langsung direturn sebagai undefined .

console.log(data?.address?.location?.pluscode); // undefined

See? Code kita jauh lebih singkat dan udah dihandle sama Javascript kalo ada error-error.

Selain object literal, optional chaining ini juga bisa digunain di array.

// normal condition
let arr = [1, 2, 3, 4]

if (arr.length > 0) {
  arr.map(val => console.log(val));
}

Dari snippet di atas kita ingin melakukan mapping kalau misal data arr punya length > 0 . Tapi kalo ternyata ada update di code kita, dimana arr bisa aja null/undefined maka code di atas enggak bakal valid. Untuk bikin handle kondisi baru tersebut kita bisa pake dua cara.

// abnormal condition
let arr = null;

// normal approach
if (Array.isArray(arr) && arr.length > 0) {
  arr.map(val => console.log(val));
}

// optional chaining #1
if (arr?.length > 0) {
  arr.map(val => console.log(val));
}

// optional chaining #2
arr?.map(val => console.log(val));

Optional chaining bukan cuma handle nullable object property, bahkan bisa handle object prototype di Javascript. Jadi kita juga bisa meng-optional chainingkan kaya .length, .map, .filter, .any, etc. .

Masih ada lagi, optional chaining ini bisa dipakai dengan expression, untuk akses item di suatu array, atau function callback.

Optional chaining ini bener-bener penyelamat banyak developer Javascript karena code yang ditulis bisa jauh lebih singkat, juga banyak library yang udah mulai support fitur ini tanpa perlu menambahkan Babel plugin. Tapi kalau kamu pengen menikmati fitur ini di project yang lumayan lama kamu perlu install @babel/plugin-proposal-optional-chaining .

Numeric Separator

Kita sebagai developer yang sehari-hari dihadapkan dengan text editor yang punya font begitu-gitu aja pasti sering banget kerepotan kalo harus berurusan dengan angka yang digitnya banyak. Takut kalo salah antara ribuan dan puluh atau ratus ribuan. Padahal cuma jarak 1 digit tapi bener-bener bisa berefek ke banyak bagian di aplikasi kita.

Tenang kisanak, karena kayaknya banyak juga developer lain yang mengalami hal ini, sekarang udah ada support untuk numeric separator.

// Before: 
let number = 1000000000; // ini berapa sih?

// After: 
let number = 1_000_000_000; // oh 1 milyar toh ternyata

Seperti namanya numeric separator ngasih bantuan kita untuk kasih separator di angka-angka yang dirasa bisa bikin kita kebingungan. Aku pertama kali nemu fitur numeric separator ini di Ruby ketika #100DaysOfCode round 1 tahun lalu.

Di Ruby kita bisa pisahin angka-angka pake underscore ( _ ) dan menurutku membantu banget, saat itu aku udah sempet rasan-rasan “kayaknya asyik nih kalo Javascript ada beginian”. Ternyata ada teman-teman!

Ohiya numeric separator ini enggak harus dipake untuk misah per 3 digit, kita bisa juga tulis dengan pattern yang ngasal dan tetep bisa jalan dengan baik kok.

let number = 1_234_5_6789_0;

Setahuku ini sebenernya fitur yang ada di ECMAScript 2021, tapi sejak tahun lalu aku udah sempet pake di beberapa project. Aku belum tau apakah library sekarang ini udah full support fitur ini, tapi cari aman bisa install dulu @babel/plugin-proposal-numeric-separator , then you are ready to go.

Path aliasing with VSCode

Pernah nggak sih ketika kita udah punya project aplikasi yang cukup gede dengan struktur folder yang udah dalem terus import kita jadi jelek banget karena kebanyakan titik-titiknya ../../../ ? Memangnya codebase kita ini morse apa gimana?

// Before: 
import SomeComponent from "../../../../../lib/SomeComponent";

// After: 
import SomeComponent from "Libs/SomeComponent";

Dengan path aliasing, kita bisa mempersingkat import kita supaya enggak kepanjangan, sekali lagi code kita bisa jadi lebih kebaca dengan baik.

Kalo aku lihat, sebenernya fitur ini udah ada lumayan lama di webpack dan kayaknya aku udah sempet nyobain, tapi saat itu kita enggak bisa manfaatin intellisense dari VSCode kita (kayaknya, entah mungkin aku yang enggak tau).

Nah dengan nambahin jsconfig.json atau tsconfig.json di VSCode dan nambahin baseUrl serta nambahin konfigurasi resolve di webpack, kita udah bisa memanfaatkan path aliasing yang tersinkron dengan VSCode.

// jsconfig.json
{
  "baseUrl": "./src",
  "include": ["./src"],
  // rest of the config...
}

// webpack config
module.exports = {
  //...
  resolve: {
    alias: {
      src: path.resolve(__dirname, "./src")
    }
  }
}

Voila! Sekarang kamu bisa ngoding tanpa perlu khawatir codebase mu yang agak besar itu berubah jadi sandi morse semua isinya.

JSDoc

Aku udah sempet bahas terkait JSDoc ini di story terpisah yang ngebahas tentang code commenting. Long story short, JSDoc ini ngebikin comment kita jadi smart, karena ketika kita ninggalin comment di code kita pakai standard JSDoc, IntelliSense dari VSCode ataupun text editor lain yang punya IntelliSense bakal bisa ngasih suggestion ketika kita mau pake method/function kita tadi.

Selain itu JSDoc juga bisa jadi guide buat kita yang mau migrasi dari Javascript ke Typescript.

Itu tadi empat fitur keren Javascript yang aku temuin sepanjang tahun 2020 kemarin, aku udah sempet intip-intip beberapa fitur di ES2021 dan juga keren-keren sih, meskipun belum tau apakah bakal ketemu case yang pake fitur itu.

Apa fitur keren Javascript yang udah pernah kamu temuin dan kamu cobain? Tinggalin di kolom komentar ya.

Have a great day. Jangan lupa pake masker!

JSDoc

Javascript Features Appreciation — 2020 was originally published in Bahas Javascript on Medium, where people are continuing the conversation by highlighting and responding to this story.

Real programmers don’t comment their code, if it’s hard to write, it should be hard to understand.
- Anonymous

Developer pasti enggak asing dengan istilah bernama clean code dan spaghetti code. Clean code sendiri merupakan sebuah konsep atau discipline dalam menulis kode dengan tujuan kode dapat mudah dipahami, diubah, dan dites. Bertolak belakang dengan spaghetti code, yang merupakan “ejekan” untuk kode yang enggak terstruktur dan susah dimaintain.

Spaghetti code biasanya terjadi karena beberapa faktor, kaya project requirement yang gampang berubah-ubah, kurangnya rule di programming style nya, juga bisa jadi karena kurangnya pengalaman dari si programmernya, and the thing is… Kita akan menjumpai hal ini di awal-awal kita belajar programming, and it is fine. Selama enggak berlarut-larut, karena bisa bahaya apalagi kalo ngerjain sesuatu dalam sebuah tim.

Clean code hadir untuk mengatasi masalah-masalah yang mungkin muncul ketika project dikerjakan oleh banyak orang. Saya sendiri merasa terbantu sejak pelan-pelan menerapkan clean code di kode saya. Penamaan yang jelas, flow yang lebih teratur, formatting yang baik, bener-bener mengurangi WTFPM (WTF Per Minute) — ukuran kualitas kodemu — ketika saya harus melihat masa lalu, maksudnya ngelihat kode yang pernah saya tulis sebelumnya.

Masalahnya… Clean code adalah konsep buatan manusia bernama Robert “Uncle Bob” Martin, yang mana tentu enggak sempurna. Enggak sempurna disini maksudnya enggak bisa diterapkan as it is dalam semua kondisi, karena berbeda kasus yang ditemui bisa jadi perlu ada adjustment. Dan salah satu adjustment yang saya maksud adalah code comments.

Mungkin agak gimana gitu ya? Terutama untuk temen-temen penganut paham clean code garis keras.

“Code is self-documenting”, they say.

Wait up… Listen to me first. Bear with me.
Saya juga percaya dan yakin bahwa kode yang baik adalah kode yang bisa dipahami “dalam sekali lihat”, kode ini ngapain, nge eksekusi apa aja, kalo error apa yang dia lakuin, dan sebagainya dan sebagainya. Kode yang baik jauh lebih baik daripada comments, tapi dalam beberapa hal kamu akan butuh comments dan clean code != well engineered.

Kenapa sih comments sebegitunya di”benci”?

Here’s my opi🧅.

Comments dipercaya sebagai code smells, alias bagian yang sukanya menuh-menuhin kode doang, bagian yang enggak penting. Saya juga dulunya mikir gitu, pokoknya code itu harus zero comments.

Sebenernya… Bukan comments yang salah dalam kode kita, tapi gimana penggunaan comments yang kurang optimal lah yang salah di kode kita. Kadang kita menggunakan comments disini-disana-dimana-mana hati kita senang sampe-sampe kode kita over-commented dan jadi code smells.

Talk is easy, show me the code

Naruh comments di kode yang udah jelas

Naruh comments di bagian-bagian kode yang udah jelas tanpa perlu dijelasin lagi adalah salah satu aspek kenapa comments jadi nggak penting, dan ya emang kaya gini enggak penting sih.

Bertele-tele

// when being used, the tutorial window will be opened to show the tutorial
const displayWindow = () => {  
  ... your code goes here
}

Comments yang panjang dan bertele-tele juga bisa bikin kita sebagai programmer ill feel sendiri bacanya. Gunakanlah comments dengan bahasa yang sederhana

Comments yang… enggak berhubungan sama sekali

// why am I being here
const getAllProducts = (params) => {
  ... your code goes here

  .. some parameters, if else, loop, whatever
}

...

// THE BOSS IS A NUISANCE DAMMIT, WHY DID HE TAKE MY BURGER
const capitalizeWord = word => {
  ...your code goes here
}

...

// I know this function sucks, I know it very well, you can call me idiot

Menambahkan comments di bagian yang enggak ada korelasinya sama kode yang dimaksud atau menjadikan comments sebagai tempat curhat karena yakin enggak bakal dibaca orang lain juga enggak boleh dilakukan ya kawanku.

Dan mungkin lebih banyak lagi kesalahan penggunaan comments yang bikin kita sebegitu enggak sukanya sama dia dan nganggep comments itu code smell.

Cara memanfaatkan comments (dengan baik?)

Comments memang bukan bagian untuk menjelaskan sebuah kode itu ngapain aja, tapi lebih ke kenapa ada kode itu disitu, kenapa kita pake cara itu dan enggak pake cara yang lain, juga bisa dipakai sebagai catatan buat orang yang lain ketika mau pake kode kita.

Documentation comments

Seperti namanya, comments ini digunakan untuk mendokumentasikan fungsi atau kode yang telah kita tulis (saya sih biasanya nulis ini buat di functions). Sebaiknya untuk comments ini menggunakan standard comments yang sudah ada, kalo Javascript ya pake standard JSDoc.

Karena kalau ngikutin standard yang ada, bisa terintegrasi dengan intellisense yang ada di code editor kesayangan kita.

Contoh paling gampang yang sering saya pake adalah untuk mendeskripsikan function yang punya parameter yang berpotensi banyak.

Kenapa enggak pake object destructuring sih? Kan lebih gampang.
Well saya juga setuju, kalau isi objectnya sedikit kita bisa gunakan object destructuring. Tapi gimana kalo objectnya bisa terdiri dari sampe 12 property? Justru bisa berpotensi jadi kotor dan susah dimaintain.

Anyway, disinilah magic nya, dengan menjelaskan parameter yang bisa ditampung lewat comments, ketika kita mau pake di file lain, terus kita lupa parameternya apa aja, kita tinggal “peek” fungsi tadi dan akan kelihatan penjelasannya.

Bahkan tanpa kita harus repot-repot buka file yang ada fungsi tadi berada. Kode fungsi kita jadi tetep sederhana, tetep bisa didebug dengan baca comment yang ada, dan terintegrasi dengan code editor kita.

By the way, comments itu bisa di collapse/expand loh di VS Code, enggak perlu khawatir menuh-menuhin. 😉

Clarification comments

Selain menggunakan comments sebagai alat buat ngebantuin kita dokumentasiin kode kita, kita juga bisa memanfaatkan comments untuk ngasih klarifikasi tentang “kenapa ada ini” di kode kita.

Penggunaan comment di snippet di atas menjelaskan kenapa sih kita pake ini dan enggak pake yang lainnya. Terus juga ngasih catatan kalo misal kodenya mau diubah approachnya apa yang harus dilakukan.

Kita juga bisa meninggalkan comments dengan bentuk lain kaya

// TODO: ...

Comment ini bisa sebagai flag buat kita terkait apa yang belum dilakukan dan nanti perlu dilakukan. Bisa juga sebagai catatan untuk orang lain kalo ada logic yang belum selesai dan warning kalo misal nanti mau pake ini ada sesuatu yang kurang beres

atau misal snippet dari Lodash

function addSetEntry(set, value) {
  /*
    Don't return `set.add` because it's not chainable in IE 11.
  */

    set.add(value);

    return set;  
}

Comments bisa level up kode kita dan bisa juga downgrade kode kita, tergantung gimana kita memanfaatkan fitur comments di kode kita. Tetep menerapkan clean code dan menggunakan comments di saat-saat yang memang diperlukan dan hindari comments yang tidak diperlukan.

Enggak perlu terlalu garis keras dengan clean code dan jadi anti dengan menggunakan comments. Karena kita sebagai programmer — terutama yang kerja bareng tim — sebaiknya mengutamakan kenyamanan dan kemudahan kita dalam mantain kode kita.

Me five years ago: code should be "clean" and self-documentingMe today: pic.twitter.com/2bBLMhIY5n

Karena pada akhirnya menurut saya kode yang baik adalah kode yang dapat dipahami dengan mudah oleh orang lain, bisa jadi orang lain itu adalah kita sendiri di masa yang akan datang.

“Any fool can write code that a computer can understand. Good programmers write a code that humans can understand”
- Martin Fowler

Tambahan:

Don't treat your colleagues like compilers 🙅‍♂️ Write your code for humans - you aren't going to "lose points" if you leave helpful hints or little breadcrumbs to indicate how and why you've done things a certain way.

Referensi:

• Summary of clean codes
• Gojek Engineering: The basics of writing clean code
• WTF Per Minute: An Actual Measurement for Code Quality
• Clean Code — Comments and Formatting by TSM
• Pros and Cons of comments in code
• Biggest code commenting fails
• Putting comments in code: the good, the bad, the ugly

Code commenting? was originally published in Bahas Javascript on Medium, where people are continuing the conversation by highlighting and responding to this story.

Melanjutkan pembahasan di post sebelumnya terkait mental model wire dari Dan Abramov dan assigning value. Seperti yang aku ceritain sebelumnya assigning value bisa kita bayangin kaya menghubungkan suatu kabel (yang mana disebut variable) ke suatu value.

Kelihatannya sih sederhana banget, padahal… ya emang sederhana sih. Menggambarkan hubungan antara value dan variable dengan kabel menurutku cara paling mudah memahami gimana variable di Javascript bekerja. Tapi eh tapi, ada beberapa hal yang mungkin perlu kamu tahu terkait gimana sih sebenernya Javascript nge-handle assigning value ini.

Let’s dive deeper into assign value…

Assign a primitive value to a variable

Let’s say kita punya potongan kode kaya gini

let lauk = "Soto";
let sayur = lauk;

Kalo mengingat implementasi mental model wire kemarin, maka hasilnya kurang lebih akan begini kan…

Karena variable sayur juga dihubungkan ke value dari variable lauk . Tapi gimana kalo kita punya potongan kode kaya gini?

let lauk = "Soto";
let sayur = "Soto";

Apakah Javascript akan membuat value Soto lagi dan kemudian dihubungkan dengan variable sayur ? Atau malah variable sayur tetap terhubung ke tempat yang sama dengan variable lauk ? Coba dengan pengetahuanmu yang sekarang kira-kira dulu apa jawabannya…

.

.

.

Udah ya…? Udah dikira-kira ya? Fix ya ini jawabannya?

.

.

.

Jawabannya, variable sayur akan terhubung ke value yang sama dengan variable lauk .

Loh kok bisa gitu? Kan kita tadi assign value sendiri-sendiri? Kok terhubung ke value yang sama sih, harusnya beda dong?!

Mungkin kamu berpikir demikian, tapi ingat-ingat lagi bahwa 1) Javascript adalah salah satu bahasa pemrograman tingkat tinggi (jauh dari memory control); 2) Primitive value itu immutable/read-only.

Dengan ingat dua hal tadi, kita bisa tahu kalo ya karena primitive value merupakan value yang read-only kenapa harus dibuatkan value lagi di tempat yang berbeda terus dihubungkan?

Terus gimana misalnya kita punya kode kaya gini…

let lauk = "Soto";
let sayur = lauk;
sayur = "Sate";

Dari potongan kode di atas, variable sayur akan diganti dari sebelumnya terhubung ke Soto berpindah ke Sate .

Karena ketika variable di assign ke primitive value dengan value yangberbeda, maka Javascript akan membuat value baru (tentunya) dan menghubungkan variable tadi ke value yang baru.

Jadi berapapun variable yang ada, kalau value yang di assign sama dan primitive value, maka Javascript akan menghubungkan semua variable ke satu value yang sama.

Oke, kalo gitu gimana dengan Object?

Assign object value to a variable

Sama seperti sebelumnya kita akan coba lihat, misal kita punya potongan kode kaya gini…

let sherlock = {};
let watson = sherlock;

Dari potongan kode di atas, dengan mental model wire kita pasti udah bisa membayangkan gimana Javascript menghubungkan value dari variable sherlock dan watson . Betul sekali kawanku, tentunya terhubung ke satu value yang sama.

Terus kira-kira gimana kalo kita ubah kode kita jadi kaya gini…

let sherlock = {};
let watson = {};

Apakah aturan di primitive value juga berlaku di object value? Bahwa akan tetap menunjuk ke satu value yang sama. Atau enggak kaya gitu? Coba kira-kira dulu, menurutmu apa yang akan dilakukan Javascript…

.

.

.

Udah punya jawaban? Yakin ya? Kita kunci jawabannya.

.

.

.

Jawabannya…

Ketika berkutat dengan object, Javascript akan selalu membuat value baru, meskipun kita menulis isi dari objectnya sama atau sama-sama empty object {} . Ini juga jadi salah satu alasan kenapa ketika kita melakukan comparison{} == {} akan me-return false , karena valuenya sudah dianggap beda oleh Javascript.

Masih ngomongin object, kira-kira gimana sih gambaran kalo object yang punya property?

let detective = {
  name: "Sherlock Holmes"
  address: "Baker Street"
};

Selalu ingat bahwa variable terhubung dengan suatu value, ketika kita ngomongin object yang punya property, maka key dari property tadi berlaku sebagai variable dan valuenya (ya jadi value, namanya juga value). Maka bisa kita gambarkan kaya gini…

See? Kita menghubungkan variable detective ke suatu object, kemudian tiap variable di dalam object tadi terhubung dengan suatu value. Gambaran ini juga bisa diperdalam lagi misalnya kita punya kode yang sedikit lebih kompleks.

let detective = {
  name: "Sherlock Holmes",
  address: {
    street: "Baker Street",
    city: "London"
  }
};

Dari potongan kode di atas bisa kita ilustrasikan seperti ini

No Nested Object
Dan Abramov di salah satu coursenya di Just Javascript bilang bahwa meskipun dalam kode kita tertulis bahwa object kita terlihat “nested”, tapi enggak ada yang namanya object di dalam object. Bisa kita lihat ilustrasi di atas kita bisa lihat bahwa sebenernya ada dua pasang curly braces yang artinya keduanya adalah entitas object yang sebenernya terpisah.

Makanya ketika kita melakukan mutation ke object yang terhubung ke address , secara otomatis value di detective.address juga ikut berubah.

let detective = {
  name: "Sherlock Holmes",
  address: {
    street: "Baker Street",
    city: "London"
  }
};
let address = detective.address;
address.city = "Liverpool";

Lalu gimana kalo kita pengen address punya value yang sama tapi menunjuk ke object yang berbeda?

Jawabannya ya dengan membuat object baru.

let address = {
  street: "Baker Street",
  city: "London"
};

Dengan begitu Javascript akan membuatkan object baru untuk dihubungkan dengan variable address , meskipun property name nya sama, karena ada di object yang berbeda, akan terhubung ke value yang berbeda.

Dengan begitu ketika kita mengubah value address.city enggak akan mempengaruhi value yang dihubungkan dengan detective.address.city lagi.

NB: Karena function juga sejatinya sebuah object, hal yang sama berlaku juga dengan function.

That’s it! Gimana Javascript memperlakukan variable ketika kita melakukan assign value. Semoga bermanfaat, happy coding!

I’m open for feedback anyway, just let me know in the comment section.

Assigning Value: Under the Hood was originally published in Bahas Javascript on Medium, where people are continuing the conversation by highlighting and responding to this story.