DEV Community: phatsss

JavaScript EP7: Promises & Async/Await⏳🪄

phatsss — Sat, 06 May 2023 14:10:41 +0000

ເຄີຍຮັບມືກັບ JS code ທີ່ແບບວ່າ...ມັນບໍ່ໄດ້ເຮັດວຽກຕາມທີ່ເຮົາຄາດຫວັງໄວ້ບໍ່? ອາດຈະເບິ່ງຄືກັບວ່າ function ຕ່າງໆຖືກ execute ແບບສຸ່ມ-ໝາຍຄວາມວ່າເຮົາບໍ່ສາມາດຄາດເດົາເວລາທີ່ໃຊ້ໃນການ execute ໄດ້ເລີຍ ຫຼື ເກີດເຫດການທີ່ວ່າການ execute ລ່າຊ້າ, ມື້ນີ້ເຮົາຈະມາເບິ່ງ feature ສຸດຄັກທີ່ຊື່ວ່າ Promises ຂອງ JavaScript ນຳກັນ🧙🏻‍♂️.

ຖ້າໃຜຍັງບໍ່ໄດ້ອ່ານ EP1 ທີ່ໄດ້ອະທິບາຍເຖິງການເຮັດວຽກຂອງ Event Loop, ແນະນຳໃຫ້ກັບໄປອ່ານກ່ອນ, ເນື່ອງຈາກມັນເປັນເນື້ອຫາທີ່ກ່ຽວຂ້ອງກັນ.
JavaScript EP1: Event Loop♻️

ເມື່ອເຮົາຂຽນ JS ສິ່ງໜຶ່ງທີ່ເຮົາມັກຈະຕ້ອງໄດ້ພົບຢູ່ຕະຫຼອດກໍ່ຄືການຈັດການ tasks ທີ່ມີການເຮັດວຽກກັບ tasks ອື່ນໆ, ສົມມຸດວ່າເຮົາຕ້ອງການທີ່ຈະ get image, compress, ໃສ່ filter ແລະ ບັນທຶກຮູບນັ້ນໆຈະມີຂັ້ນຕອນການເຮັດວຽກດັ່ງນີ້:

ສິ່ງທຳອິດທີ່ເຮົາຈະເຮັດກໍ່ຄືການດຶງເອົາຮູບທີ່ເຮົາຕ້ອງການແກ້ໄຂ(get image), ເຮົາມີ getImage function ທີ່ຈະເຮັດວຽກໃນສ່ວນນີ້.
ຫຼັງຈາກໄດ້ຮູບມາແລ້ວຕໍ່ມາຈະເປັນການ resize image ຈະເປັນສ່ວນຂອງ compressImage function ຮັບໄມ້ຕໍ່.
ເມື່ອ resize image ສຳເລັດເຮົາຕ້ອງການໃສ່ filter ເຊິ່ງເຮົາມີ applyFilter function ຮັບໜ້າທີ່ສ່ວນນີ້ໄປ.
ສຸດທ້າຍແມ່ນຈະເປັນການບັນທຶກຮູບພາບໂດຍໃຊ້ saveImage function ຖ້າຫາກບໍ່ມີຫຍັງຜິດພາດກໍ່ຈະທຳການແຈ້ງໃຫ້ user ຮູ້ວ່າໄດ້ທຳການບັນທຶກຮູບພາບສຳເລັດ.

ສຸດທ້າຍເຮົາຈະໄດ້ code ປະມານນີ້:

ສັງເກດເຫັນຫຍັງບາງຢ່າງບໍ່? ຮູ້ສຶກວ່າໃນ code ຂອງເຮົາມີການໃຊ້ nested callback functions ຫຼາຍເກີນໄປເຊິ່ງມັນພັດຂຶ້ນກັບ callback ກ່ອນໜ້າອີກ. callback ໃນລັກສະນະນີ້ມັກຖືກເອີ້ນວ່າ callback hell🤯 ເນື່ອງຈາກມັນມີ callback function ຊ້ອນກັນຫຼາຍເກີນໄປຈຶ່ງເຮັດໃຫ້ code ອ່ານຍາກຂຶ້ນໄປອີກ.

ໂຊກດີທີ່ເຮົາມີສິ່ງທີ່ເອີ້ນວ່າ promises ທີ່ຈະເຂົ້າມາຊ່ວຍເຮົາຈັດການກັບບັນຫາແບບນີ້, ເຮົາໄປທຳຄວາມຮູ້ຈັກກັບ promises ນຳກັນແບບເລິກໆກັນເລີຍ🫡.

Promise Syntax

ຖ້າໃຜເຄີຍໄດ້ອ່ານບົດຄວາມ ຫຼື ເອກະສານໃດໆກໍ່ຕາມທີ່ອະທິບາຍກ່ຽວກັບ Promises ກໍ່ອາດຈະຄຸ້ນຕາກັບນິຍາມ ຫຼື ຄຳອະທິບາຍ Promises ປະມານວ່າ:

"A promise is a placeholder for a value that can either resolve or reject at some time in the future"

ຖ້າຈະເບິ່ງຕາມນິຍາມ ໂດຍສ່ວນຕົວຜູ້ຂຽນເອງກໍ່ຍັງຮູ້ສຶກວ່າມັນຍັງຄຸມເຄືອ ແລະ ບໍ່ຊັດເຈນໃນບາງຈຸດຢູ່, ເພື່ອໃຫ້ເຮົາເຂົ້າໃຈຫຼາຍຂຶ້ນ ເຮົາມາເບິ່ງລັກສະນະການເຮັດວຽກຂອງມັນແທ້ໆເລີຍດີກວ່າ.
ເຮົາສາມາດສ້າງ promise ໂດຍໃຊ້ Promise constructor ທີ່ມີການຮັບ callback function ດັ່ງນີ້:

ເຫັນຫຍັງບໍ່ວ່າມີຫຍັງທີ່ຖືກ return ອອກມາ?
Promise ເປັນ object ໜຶ່ງທີ່ທາງໃນປະກອບມີ status([[PromiseStatus]]) ແລະ value([[PromiseValue]]). ໃນຕົວຢ່າງດດ້ານເທິງເຮົາຈະເຫັນວ່າ value ຂອງ [[PromiseStatus]] ແມ່ນ "pending" ແລະ value ຂອງ promise ແມ່ນ undefined.
ແຕ່ບໍ່ຕ້ອງຫ່ວງ, ເຮົາບໍ່ໄດ້ເຮັດຫຍັງກັບ object ນີ້ດອກ. ໃນຄວາມເປັນຈິງເຮົາບໍ່ສາມາດ access [[PromiseStatus]] ແລະ [[PromiseValue]] properties ໄດ້, ແຕ່ value ຂອງທັງ 2 properties ນີ້ແມ່ນສຳຄັນຫຼາຍເມື່ອເຮົາໃຊ້ promise.

value ຂອງ PromiseStatus ຫຼື state ສາມາດເປັນ 1 ໃນ 3 values ດັ່ງນີ້:

✅ fulfilled: promise ໄດ້ທຳການ resolved ໝາຍຄວາມວ່າທຸກຢ່າງເຮັດວຽກໄດ້ສຳເລັດ, ບໍ່ມີ error ໃດໆເກີດຂຶ້ນໃນ promise.
❌ rejected: promise ໄດ້ທຳການ rejected ໝາຍຄວາມວ່າມີບາງຢ່າງຜິດພາດ ຫຼື ອາດຈະເກີດ error ຫຍັງບາງຢ່າງໃນ promise.
⏳ pending: promise ຍັງບໍ່ມີການ resolved ແລະ ໃນຂະນະດຽວກັນກໍ່ຍັງບໍ່ rejected ເຊັ່ນກັນ, ເຊິ່ງມັນຍັງ pending ຢູ່.

ແລ້ວຕອນໃດທີ່ promise status ຈະເປັນ "pending", "fulfilled" ຫຼື "rejected"? ແລະ ສະຖານະຂອງ promise ມັນສຳຄັນຈັ່ງໃດ?

ໃນຕົວຢ່າງດ້ານເທິງເຮົາໄດ້ທຳການ pass callback function () => {} ເຂົ້າໄປໃນ promise constructor. ແຕ່ໃນ callback function ຈະມີການຮັບອີກ 2 arguments, ເຊິ່ງ value ຂອງ argument ທຳອິດເອີ້ນວ່າ resolve ຫຼື res ເປັນ method ທີ່ຈະຖືກເອີ້ນເມື່ອ Promise ທຳການ resolve ແລະ
argument ທີ 2 ເອີ້ນວ່າ reject ແລະ rej ເປັນ method ທີ່ຈະຖືກເອີ້ນຕອນທີ່ Promise ທຳການ reject ຫຼື ມີບາງຢາດຜິດພາດ.

ມາເບິ່ງກັນວ່າເມື່ອເຮົາເອີ້ນໃຊ້ resolve ຫຼື reject method ຈະໄດ້ຜົນລັບແນວໃດ:

ໃນທີ່ສຸດເຮົາກໍ່ຮູ້ວິທີທີ່ເຮັດໃຫ້ promise status ບໍ່ເກີດສະຖານະ "pending" ແລະ undefined value. status ຂອງ promise ຈະເປັນ "fulfilled" ຖ້າເຮົາເອີ້ນໃຊ້ resolve method ແລະ status ຈະເປັນ "rejected" ຖ້າເຮົາເອີ້ນໃຊ້ rejected method.
ລອງມາເບິ່ງໃນສ່ວນຂອງ value ຂອງ promise ກັນຕື່ມ, ເຊິ່ງ value ຂອງ [[PromiseValue]] ຈະເປັນ value ທີ່ເຮົາ pass ເຂົ້າໄປໃນ resolved ຫຼື rejected method ໃນຮູບແບບຂອງ argument ຂອງມັນ.

ມາຮອດຕອນນີ້ເຮົາພໍຈະຮູ້ວິທີຈັດການກັບ Promise object ໃນລະດັບໜຶ່ງແລ້ວ, ຄຳຖາມຕໍ່ມາກໍ່ຄື ມັນໃຊ້ໄວ້ເພື່ອຫຍັງ?🧐.

ໃນຕົວຢ່າງແລກໆແມ່ນເຮົາໄດ້ເຫັນຕົວຢ່າງທີ່ເຮົາໄດ້ທຳການ get image, compress, ໃສ່ filter ແລະ ບັນທຶກຮູບພາບກັນໄປແລ້ວ, ສຸດທ້າຍເຮົາກໍ່ໄດ້ code ທີ່ມີ nasted callback function ແບບເບິ້ມໆມາຊຸດໜຶ່ງ.

Promise ກໍ່ສາມາດນຳມາແກ້ບັນຫາທີ່ວ່າມາໄດ້ເຊັ່ນກັນ, ແຕ່ກ່ອນອື່ນໝົດເຮົາຕ້ອງໄດ້ທຳການຂຽນ code ໃໝ່, ເຊິ່ງເຮົາຈະໃຫ້ແຕ່ລະ function ທຳການ return Promise ແທນ.
ຖ້າຫາກໂຫຼດຮູບສຳເລັດ ແລະ ທຸກຢ່າງເຮັດວຽກໂດຍທີ່ບໍ່ມີ error ໃດໆ, ເຮົາຈະທຳການ resolve promise ດ້ວຍໄຟລ໌ທີ່ຖືກໂຫຼດມາແລ້ວ ໃນທີ່ນີ້ຈະເປັນ image ແລະ ຖ້າຫາກເກີດ error ໃນຂະນະທີ່ທຳການໂຫຼດໄຟລ໌ ເຮົາຈະທຳການ reject promise ດ້ວຍການໂຍນ error ອອກມາແທນ.

ເມື່ອເຮົາລອງສັ່ງ run code ດັ່ງກ່າວຈະໄດ້ຜົນລັບດັ່ງນີ້:

ຈະເຫັນວ່າ Promise ໄດ້ທຳການ return value ຂອງ parsed data.

ແລ້ວແນວໃດຕໍ່? ເຮົາຈະບໍ່ສົນໃຈ promise object ທັງໝົດທີ່ວ່າມາ, ເຮົາສົນໃຈພຽງ value ຂອງ data ທີ່ຖືກໂຍນອອກມາເທົ່ານັ້ນ, ມັນຈະມີ built-in methods 3 ໂຕທີ່ເຮັດໃຫ້ເຮົາສາມາດດຶງ promise value ອອກມາໃຊ້ໄດ້.

.then(): ຖືກເອີ້ນເມື່ອ promise ຖືກ resolved.
.catch(): ຖືກເອີ້ນເມື່ອ promise ຖືກ rejected.
.finally(): ຈະຖືກເອີ້ນທຸກຄັ້ງບໍ່ວ່າ promise ຈະ resolved ຫຼື rejected ກໍ່ຕາມ. *{ ໃນຮູບດ້ານເທິງໜ້າຈະໃສ່ມາຜິດ

.then method ຈະຮັບ value ທີ່ຖືກ pass ມາໃນ resolve method.

.catch method ຈະຮັບ value ທີ່ຖືກ pass ມາໃນ rejected method.

ໃນທີ່ສຸດເຮົາກໍ່ໄດ້ value ທີ່ຖືກ resolve ໂດຍ promise ໂດຍທີ່ບໍ່ໄດ້ຢູ່ໃນຮູບແບບຂອງ promise object, ເຊິ່ງເຮົາສາມາດນຳ value ດັ່ງກ່າວໄປເຮັດຫຍັງກໍ່ໄດ້.

ເມື່ອເຮົາຮູ້ແລ້ວວ່າ promise ຈະທຳການ resolve ຫຼື reject ທຸກໆຄັ້ງ, ດັ່ງນັ້ນເຮົາກໍ່ສາມາດຂຽນ Promise.resolve ຫຼື Promise.reject ດ້ວຍການ pass value ທີ່ເຮົາຕ້ອງການ resolve ຫຼື reject ເຂົ້າໄປໃຫ້ promise ໄດ້ດັ່ງນີ້.

ໃນຕົວຢ່າງຕໍ່ໄປກໍ່ຈະໄດ້ໃຊ້ syntax ແບບນີ້ເປັນຫຼັກ.

ຢູ່ໃນຕົວຢ່າງຂອງ getImage ເຮົາມີ nested callback function ຫຼາຍອັນ, ເຊິ່ງເຮົາກໍ່ສາມາດໃຊ້ .then ໃນການຈັດການກັບ code ສ່ວນນີ້🤩.
result ຂອງ .then ເອງກໍ່ແມ່ນ promise value ເຊັ່ນກັນ-ໝາຍຄວາມວ່າເຮົາສາມາດໃຊ້ .then ເປັນ chain ຕໍ່ກັນຫຼາຍໆ .then ເທົ່າທີ່ເຮົາຕ້ອງການໄດ້. ເຊິ່ງ result ຂອງ .then callback ກ່ອນໜ້າຈະຖືກ pass ເປັນໜຶ່ງ argument
ໃນ .then callback ຕໍ່ໄປ.

ໃນກໍລະນີຂອງຕົວຢ່າງ getImage ເຮົາສາມາດຂຽນ .then callback chain ໄດ້ເຊັ່ນກັນໂດຍເຮົາຈະທຳການ pass ໄຟລ໌ຮູບເຂົ້າໄປໃນ function ຕໍ່ໄປແທນທີ່ຈະໃຊ້ nested callback ຫຼາຍໆຊັ້ນເຊິ່ງມັນຈະເຮັດໃຫ້ code ຂອງເຮົາອ່ານງ່າຍຂຶ້ນ.

Microtasks and (Macro)tasks

ມາຮອດບ່ອນນີ້ເຮົາກໍ່ໄດ້ຮູ້ວິທີສ້າງ promise ແລະ ວິທີຈັດການກັບ values ທີ່ໄດ້ຈາກ promise ກັນໄປແລ້ວ, ເຮົາລອງເພີ່ມ script ອີກໜ້ອຍໜຶ່ງແລ້ວທຳການ run ລອງເບິ່ງອີກຄັ້ງລອງເບິ່ງ.

ເຫັນຫຍັງບໍ່?🤯 ນັ້ນມັນແບ້ຫຍັງຫັ້ນ?
ທຳອິດເຮົາຈະ log ຄຳວ່າ Start! ອອກມາ, ເຊິ່ງບ່ອນນີ້ກໍ່ເປັນຜົນມາຈາກ code ໃນແຖວທຳອິດ. ຕໍ່ມາເຮົາຈະເຫັນວ່າມັນ log ຄຳວ່າ End! ແທນທີ່ຈະເປັນ value ຂອງ Promise.resolve ແຕ່ສ່ວນນີ້ພັດຖືກ log ອອກມາຫຼັງຈາກ End!. ເຮົາມາເບິ່ງນຳກັນຕໍ່ວ່າມັນເກີດຫຍັງຂຶ້ນໃນສ່ວນນີ້.
ມາຮອດບ່ອນນີ້ເຮົາກໍ່ເຫັນແລ້ວວ່າ promises ມັນເຮັດຫຍັງໄດ້ແນ່, ເຖິງ JavaScript ມັນຈະເປັນ single-thread ແຕ່ເຮົາກໍ່ສາມາດເພິ່ມຄວາມສາມາດແບບ asynchronous ໂດຍໃຊ້ Promise ໄດ້ເຊັ່ນກັນ.
ແຕ່ຮູ້ສຶກວ່າເຮົາໄດ້ເວົ້າເຖິງເລື່ອງນີ້ໄປແລ້ວໃນບົດຄວາມ EP1: Event loop?🤔, ແຕ່ເຮົາຍັງສາມາດໃຊ້ວິທີການແບບເດີມໆທີ່ເຮົາເຄີຍເຮັດຜ່ານມາເຊັ່ນ: setTimeout ໃນການສ້າງ asynchronous behavior ບາງປະເພດໄດ້ຫຼືບໍ່?🧐🤨🤯
ແມ່ນແລ້ວ, ແຕ່ໃນ Event loop ມີຄິວ(Queues)ຢູ່ 2 ປະເພດຄື: (macro)task queue (ບາງຄັ້ງກໍ່ເອີ້ນວ່າ task queue) ແລະ microtask queue. ເຊິ່ງ (macro)task queue ກໍ່ເປັນ queue ສຳລັບ (macro)tasks ແລະ microtask queue ກໍ່ເປັນ queue ສຳລັບ microtask.
ແລ້ວ (macro)task ແລະ microtask ແມ່ນຫຍັງ?, ມາທຳຄວາມເຂົ້າໃຈໄປພ້ອມໆກັນເລີຍ.

ຈາກຕາຕະລາງຈະເຫັນວ່າ Promise ຈະຢູ່ໃນ microtask list, ເມື່ອ Promise ທຳການ resolve ແລະ ໄດ້ເອີ້ນໃຊ້ then(), catch() ຫຼື finally() method. callback ທີ່ຢູ່ໃນ method ຈະຖືກເພີ່ມເຂົ້າໃນ microtask queue ໝາຍຄວາມວ່າບັນດາ callback ທີ່ຢູ່ໃນ then(), catch() ຫຼື finally() method ຈະບໍ່ຖືກ execute ທັນທີ, ແຕ່ໂດຍພື້ນຖານແລ້ວມັນຈະທຳການເພີ່ມ async ໃຫ້ JavaScript code ຂອງເຮົາໂດຍອັດຕະໂນມັດຢູ່ແລ້ວ.
ແລ້ວ then(), catch() ຫຼື finally() callback ຖືກ execute ຕອນໃດ? event loop ຈະເປັນຕົວທີ່ຈັດການກັບ priority ໃຫ້ແຕ່ລະ tasks ແຕກຕ່າງກັນດັ່ງນີ້:

function ທັງໝົດທີ່ຢູ່ໃນ call stack ຈະຖືກ execute, ເມື່ອມັນໄດ້ທຳການ return value ອອກມາ ພວກມັນຈະຖືກໂຍນອອກ(pop)ຈາກ call stack.
ເມື່ອ call stack ວ່າງ, microtasks ທັງໝົດທີ່ຢູ່ໃນ queue ຈະຖືກໂຍນມາທີ່ callstack ເທື່ອລະຕົວ ແລະ ທຳການ execute ຕໍ່ໄປ(ໂຕ Microtasks ເອງກໍ່ຍັງສາມາດ return microtasks ໃໝ່ອອກມາໄດ້ເຊັ່ນກັນ, ເຊິ່ງມັນຈະສ້າງ infinite microtask loop ໄດ້ຢ່າງມີປະສິດທິພາບ).
ຖ້າຫາກທັງ call stack ແລະ microtask queue ວ່າງ, event loop ຈະທຳການກວດເບິ່ງ tasks ທີ່ຍັງຄ້າງຢູ່ໃນ (macro)task queue ວ່າຍັງມີຫຼືບໍ່?, ຖ້າມີມັນກໍ່ຈະຖືກໂຍນມາທີ່ callstack ເພື່ອທຳການ execute ແລະ ເມື່ອ return value ອອກໄປແລ້ວມັນຈະທຳການໂຍນ task ອອກຈາກ callstack.

ເພື່ອໃຫ້ເຫັນພາບຫຼາຍຂຶ້ນ, ເຮົາມາເບິ່ງຕົວຢ່າງງ່າຍໆດ້ານລຸ່ມນຳກັນ:

Task1: function ທີ່ຖືກເພີ່ມເຂົ້າໄປໃນ call stack ຈະຖືກ execute ທັນທີ, ຕົວຢ່າງ: ການເອີ້ນໃຊ້ function ທີ່ຢູ່ໃນ code ຂອງເຮົາມັນຈະຖືກເອີ້ນໃຊ້ທັນທີ.
Task2, Task3, Task4: microtasks, ຕົວຢ່າງ: promise then callback ຫຼື task ທີ່ຖືກເພີ່ມໂດຍ queueMicrotask.
Task5, Task6: (macro)task, ຕົວຢ່າງ: setTimeout ຫຼື setImmediate callback. ທຳອິດ Task1 ຈະທຳການ return value ແລະ ຈະຖືກໂຍນອອກຈາກ call stack. ຈາກນັ້ນ engine ຈະກວດເບິ່ງ tasks queue ທີ່ຢູ່ໃນ microtask queue. ເມື່ອ tasks ທັງໝົດຖືກເພີ່ມເຂົ້າໄປໃນ call stack ແລະ ຖືກໂຍນອອກໃນຕອນສຸດທ້າຍ engine ຈະທຳການກວດເບິ່ງ task ທີ່ຍັງເຫຼືອໃນ (macro)task queue ຕໍ່ ແລະ ຈະທຳການເພີ່ມເຂົ້າໄປໃນ call stack ແລະ ໂຍນອອກຫຼັງຈາກທີ່ມັນໄດ້ທຳການ return value ອອກມາ.

ດຽວເຮົາມາເບິ່ງຈາກ code ເລີຍດີກວ່າ.

ໃນ code ດ້ານເທິງເຮົາມີ macro task ແມ່ນ setTimeout ແລະ microtask ແມ່ນ promise then() callback, ເມື່ອ engine ເຮັດວຽກມາຮອດແຖວຂອງ setTimeout function ຈະເກີດຫຍັງຂຶ້ນ? ເຮົາໄປເບິ່ງການເຮັດວຽກຂອງແຕ່ລະຂັ້ນຕອນນຳກັນເລີຍວ່າເຮົາຈະເຫັນຫຍັງໃນ log ແນ່.

ປລ: ໃນຕົວຢ່າງຕໍ່ໄປແມ່ນຈະສະແດງເຖິງບັນດາ methods ເຊັ່ນ: console.log, setTimeout ແລະ Promise.resolve ທີ່ຖືກເພີ່ມເຂົ້າໄປໃນ call stack. ເຊິ່ງພວກມັນເປັນ internal methods ດັ່ງນັ້ນເຮົາອາດຈະບໍ່ເຫັນມັນປາກົດຢູ່ໃນ stack traces, ແຕ່ບໍ່ຕ້ອງຕົກໃຈໄປ ຖ້າຫາກໃຊ້ debugger ແລ້ວບໍ່ເຫັນ ເນື່ອງຈາກເຮົາຕ້ອງການຍົກຕົວຢ່າງໃຫ້ເຫັນຄອນເຊັບຂອງການເຮັດວຽກຂອງມັນໂດຍທີ່ບໍ່ໄດ້ຂຽນ code ທີ່ຊັບຊ້ອນຫຍັງ.

ໃນແຖວທຳອິດ, engine ຈະພົບ console.log() method, ມັນຈະຖືກເພີ່ມເຂົ້າໄປໃນ call stack ຫຼັງຈາກນັ້ນມັນຈະ log ຄ່າ Start! ອອກມາຜ່ານ console ແລະ method ດັ່ງກ່າວຈະຖືກໂຍນອອກຈາກ call stack ແລ້ວ engine ກໍ່ຈະດຳເນີນການເຮັດວຽກຂອງມັນຕໍ່ໄປ.

ຕໍ່ມາ engine ຈະພົບ setTimeout method, ເຊິ່ງມັນກໍ່ຈະຖືກເພີ່ມເຂົ້າໄປໃນ call stack. ຕົວ setTimeout method ແມ່ນເປັນ method ຂອງ browser ໂດຍທີ່ call back function ຂອງມັນ(() => console.log('Timeout'))ຈະຖືກເພີ່ມເຂົ້າໄປໃນ Web API ຈົນກວ່າ timer ເຮັດວຽກສຳເລັດ. ແຕ່ໃນທີ່ນີ້ເຮົາໄດ້ກຳນົດຄ່າໃຫ້ timer ມີຄ່າເປັນ 0 ແຕ່ call back ກໍ່ຍັງຄົງຖືກເພີ່ມລົງໄປໃນ Web API ກ່ອນຢູ່ດີ. ຫຼັງຈາກນັ້ນມັນຈະຖືກເພີ່ມເຂົ້າໄປໃນ (macro)task queue: setTimeout ເປັນ macro task.

step ຕໍ່ໄປ engine ຈະພົບ Promise.resolve() method. Promise.resolve() method ຈະຖືກເພີ່ມເຂົ້າໄປໃນ call stack, ຫຼັງຈາກທີ່ມັນທຳການ resolve ດ້ວຍ value Promise! ແລ້ວ, then callback function ຈະຖືກເພີ່ມເຂົ້າໄປໃນ microtask queue.

ເມື່ອ engine ເຮັດວຽກມາຮອດແຖວສຸດທ້າຍມັນຈະພົບ console.log() method. ມັນຈະຖືກເພີ່ມເຂົ້າໄປໃນ call stack ທັນທີ, ຫຼັງຈາກມັນໄດ້ທຳການ log ຄ່າ End! ອອກມາທາງ console ແລ້ວ ມັນຈະຖືກໂຍນອອກຈາກ call stack ທັນທີ. ສ່ວນ engine ຈະເຮັດວຽກສ່ວນທີ່ເຫຼືອຕໍ່ໄປ.

ມາຮອດບ່ອນນີ້ engine ຈະເຫັນວ່າ call stack ຂອງເຮົາວ່າງຢູ່. ເມື່ອ call stack ວ່າງມັນຈະໄປກວດເບິ່ງ task ທີ່ລໍຖ້າຢູ່ microtask queue ໃນ code ຕົວຢ່າງຂອງເຮົາຈະເຫັນວ່າຍັງມີ promise then callback ທີ່ຍັງລໍຖ້າຢູ່, ດັ່ງນັ້ນມັນຈຶ່ງຖືກໂຍນເຂົ້າໄປໃນ call stack ຫຼັງຈາກນັ້ນມັນຈະທຳການ resolve value ຂອງ promise ເຊິ່ງໃນຕົວຢ່າງແມ່ນມັນຈະ log ຄ່າ Promise!.

call stack ເຫັນວ່າຄິວວ່າງພໍດີມັນເລີຍເຂົ້າໄປກວດຢູ່ microtask queue ອີກຄັ້ງເພື່ອຊອກເບິ່ງວ່າຍັງມີ task ທີ່ຍັງຕໍ່ຄິວ(queue)ຫຼືບໍ່? ແຕ່ວ່າໃນກໍລະນີນີ້ microtask queue ກໍ່ວ່າງເຊັ່ນກັນ🤷🏻.
ເມື່ອຫາຢູ່ microtassk queue ບໍ່ເຫັນມັນຈຶ່ງທຳການໄປຫາຢູ່ (macro)task queue ຕໍ່, ເຊິ່ງໃນນີ້ຍັງມີ setTimeout callback ທີ່ຍັງຖ້າແລ້ວຖ້າອີກ ແຕ່ຕອນນີ້ເຖິງເວລາທີ່ຕ້ອງໂຍນເຂົ້າໄປໃນ call stack ແລ້ວ. callback function ທຳການ return console.log method ທີ່ທຳການ log ຄ່າ "Timeout!" ອອກໄປ. ຫຼັງຈາກນັ້ນ setTimeout callback ຈະຖືກໂຍນອອກຈາກ call stack.

ຈາກຕົວຢ່າງດ້ານເທິງກໍ່ນັບວ່າຈົບບໍລິບູນສຳລັບຕົວຢ່າງນີ້.

Async/Await

ES7 ໄດ້ແນະນຳວິທີໃໝ່ໃນການເພີ່ມ async behavior ໃນ JavaScript ແລະ ເຮັດໃຫ້ມັນເຮັດວຽກຮ່ວມກັບ promises ແບບງ່າຍໆ. ເຊິ່ງໃນນັ້ນຈະໃຊ້ async ແລະ await keyword ໃນການສ້າງ async functions ທີ່ສາມາດ return promise ອອກມາໄດ້, ສ່ວນວິທີການຈະເປັນແນວໃດນັ້ນ ໄປເບິ່ງນຳກັນເລີຍ.
ກ່ອນໜ້ານີ້ເຮົາໄດ້ເຫັນແລ້ວວ່າເຮົາສາມາດສ້າງ Promise ໄດ້ໂດຍໃຊ້ Promise object, ເຊິ່ງມັນກໍ່ຍັງມີອີກແບບອື່ນໆເຊັ່ນ: new Promise(() => {}), Promise.resolve, ຫຼື Promise.reject.
ແທນທີ່ຈະໃຊ້ Promise object ເຮົາສາມາດສ້າງ asynchronous functions ທີ່ return object ອອກມາໄດ້ເລີຍໂດຍທີ່ເຮົາບໍ່ຈຳເປັນຕ້ອງໄປຂຽນ Promise object ດ້ວຍຕົວເອງ.

ເຖິງແມ່ນວ່າໃນຄວາມເປັນຈິງແລ້ວ async functions ສາມາດ return promises ອອກມາໄດ້ນັ້ນກໍ່ນັບວ່າເປັນເລື່ອງດີ, ແຕ່ວ່າການທີ່ເຮົາຈະສາມາດສຳຜັດເຖິງຂຸມພະລັງທີ່ແທ້ຈິງຂອງ async functions ໄດ້ນັ້ນກໍ່ຄືຕອນທີ່ເຮົາໃຊ້ await keyword. ດ້ວຍ await keyword ເຮົາສາມາດລະງັບການເຮັດວຽກ(suspended)ຂອງ asynchronous function ໃນຂະນະທີ່ເຮົາລໍຖ້າ await value ຖືກ return ຈາກການ resolve promise ໄດ້ນັ້ນເອງ🥳. ຖ້າເຮົາຕ້ອງການ value ຂອງ promise ຫຼັງຈາກທີ່ຖືກ resolve ແລ້ວນັ້ນເຮົາກໍ່ພຽງແຕ່ເຮັດຄືຕົວຢ່າງທີ່ຜ່ານມາຄືໃຊ້ then() callback ແລະ ເຮົາຍັງສາມາດ assign variables ໃຫ້ກັບ await promise value ໄດ້ນຳ.
ມັນໝາຍຄວາມວ່າເຮົາສາມາດລະງັບການເຮັດວຽກ(suspended)ຂອງ async function ໄດ້ຫວາ? ຊິວ່າຈັ່ງຊັ້ນກໍ່ໄດ້, ແຕ່ວ່າມັນໝາຍຄວາມວ່າແນວໃດລ່ະ?.
ເຮົາໄປເບິ່ງ code ຕົວຢ່າງພ້ອມໆກັນເລີຍ:

ເກີດຫຍັງຂຶ້ນກັບ code ຂອງເຮົາແນ່?

ທຳອິດ engine ມັນຈະພົບກັບ console.log. ມັນຈະຖືກໂຍນເຂົ້າໄປໃນ call stack ຫຼັງຈາກນັ້ນມັນຈະທຳການ log ຄ່າ Before function! ອອກມາ.

ຈາກນັ້ນເຮົາໄດ້ທຳການເອີ້ນໃຊ້ async function ທີ່ຊື່ວ່າ myFunc(), ຫຼັງຈາກນັ້ນຕົວ myFunc() function ກໍ່ຈະເຮັດວຽກ. ໃນແຖວທຳອິດຂອງ function body ເຮົາໄດ້ທຳການເອີ້ນໃຊ້ console.log ອີກຄັ້ງ, ເທື່ອນີ້ມັນຈະ log ຄ່າ In function!, ເຊິ່ງ console.log ຈະຖືກໂຍນເຂົ້າໄປໃນ call stack, log ຄ່າອອກມາ ແລະ ຖືກໂຍນອອກຈາກ call stack ຕາມ step ເດີມໆ.

ໃນ function body ຍັງຄົງທຳການ execute ຕໍ່ໄປ, ເຊິ່ງເຮົາຈະເຫັນພະເອກຂອງເຮົາຄື await keyword ຢູ່ໃນແຖວທີ 2 🥳🥳🥳.

ສິ່ງທຳອິດທີ່ຈະເກີດຂຶ້ນກໍ່ຄື: value ຈະລໍຖ້າ execute, ເຊິ່ງໃນກໍລະນີນີ້ແມ່ນ one function. ມັນຈະຖືກໂຍນເຂົ້າໄປໃນ call stack ແລະ ມັນຈະທຳການ return value ຂອງ resolve promise ອອກມາ. ເມື່ອ promise ຖືກ resolve ແລ້ວ ແລະ one ໄດ້ return value ອອກມາ, ຈາກນັ້ນ engine ກໍ່ຈະພົບ await keyword.

ເມື່ອມັນພົບ await keyword ແລ້ວ, async function ຈະຖືກລະງັບການເຮັດວຽກ(suspended). ການ execute ພາຍໃນ function body ຈະທຳການຢຸດຊົ່ວຄາວ(paused) ແລະ ສ່ວນທີ່ເຫຼືອໃນ async function ຈະໄປ run ຢູ່ microtask ແທນ task ທຳມະດາແທນ.

ຕອນນີ້ async function ທີ່ຊື່ວ່າ myFunc ຈະຖືກລະງັບການເຮັດວຽກ(suspended)ໃນກໍລະນີທີ່ທັນພົບ await keyword, engine ຈະໂດດອອກຈາກ async function ແລະ ທຳການ execute code ຕໍ່ໄປໃນບໍລິບົດຂອງການ execution ທີ່ async function ຖືກເອີ້ນໃຊ້. ເຊິ່ງໃນກໍລະນີນີ້ແມ່ນ global execution context.

ສຸດທ້າຍກໍ່ບໍ່ເຫຼືອ task ໃດທີ່ຢູ່ໃນ global execution context. event loop ຈະທຳການກວດເບິ່ງວ່າພົບ microtasks ທີ່ລໍຖ້າ queue ຢູ່ຫຼືບໍ່? ແລະ ມັນກໍ່ຍັງມີ async myFunc function ທີ່ຢູ່ໃນ queue ຫຼັງຈາກທີ່ທຳການ resolve value ຂອງ one. myFunc ຈະຖືກເພີ່ມເຂົ້າໄປໃນ call stack ອີກຄັ້ງ ແລະ ທຳການ run ຕໍ່ຈາກທີ່ຄ້າງໄວ້ກ່ອນໜ້ານີ້.

ໃນທີ່ສຸດ variable res ກໍ່ໄດ້ value ອອກມາ, ເຊິ່ງມັນກໍ່ເປັນ value ທີ່ຖືກ resolve ຈາກ promise ນັ້ນກໍ່ຄື one ນັ້ນເອງ. ເຮົາໄດ້ທຳການເອີ້ນໃຊ້ console.log ດ້ວຍ value ຂອງ res ໃນກໍລະນີນີ້ແມ່ນ One!, ເຊິ່ງ One! ຈະຖືກ log ອອກມາຜ່ານ console ແລະ ມັນຈະຖືກໂຍນອອກຈາກ call stack.

ມາຮອດຕອນນີ້ກໍ່ເປັນອັນຈົບຊີຣີ່ຂອງ JavaScript ພື້ນຖານ(ແບບສຸດໆ), ຈາກຫຼາຍໆຕົວຢ່າງຜ່ານມາເຮົາກໍ່ຈະເຫັນພາບແລ້ວວ່າພາສາ JavaScript ເອງມັນກໍ່ມີຈຸດທີໜ້າສົນໃນໃນຫຼາຍໆເລື່ອງ ແລະ ຫຼາຍໆ feature ຢູ່ບໍ່ໜ້ອຍ, ຖ້າເຮົາເຂົ້າໃຈຂະບວນການເຮັດວໜກຂອງມັນເຮົາກໍ່ຈະສາມາດຂຽນ code ໄດ້ຢ່າງມີປະສິດທິພາບຫຼາຍຂຶ້ນ ແຕ່ທັງນີ້ກໍ່ຂຶ້ນກັບຄວາມຮູ້ດ້ານອື່ນໆນຳ.

ອ້າງອີງ: ⭐️🎀 JavaScript Visualized: Promises & Async/Await

JavaScript EP6: Generators and Iterators🔌🩻

phatsss — Mon, 24 Apr 2023 10:17:09 +0000

ນັບຕັ້ງແຕ່ ES6 ເປັນຕົ້ນມາ, JavaScript ມີສິ່ງໜຶ່ງທີ່ໂຄດຄັກເລີຍນັ້ນກໍ່ຄື generator functions ເຊິ່ງຫຼາຍໆຄົນທີ່ຂຽນ JavaScript ກໍ່ອາດຈະມີບາງຄົນທີ່ໃຊ້ ແລະ ສ່ວນໃຫຍ່ກໍ່ອາດຈະບໍ່ໄດ້ໃຊ້ເລີຍ, ແຕ່ຂໍບອກໄວ້ກ່ອນວ່າມັນ cool ອີ່ຫຼີ ຢາກໃຫ້ທຸກຄົນໄດ້ລອງ🛸.

ວ່າແຕ່ generator functions ມັນແມ່ນແບ້ຫຍັງອີກແລ້ວວວວ?🤣, ທຳອິດເຮົາມາເບິ່ງ function ແບບທຳມະດາ ແລະ ແບບເດີມໆກັນກ່ອນ.

ຂ້ອຍຮູ້ວ່າພວກເຈົ້າຄິດຫຍັງຢູ່, ແຕ່ແມ່ນແລ້ວ ມັນກະແຄ່ function ທຳມະດາໆອັນໜຶ່ງ ແລະ ທາງໃນ function ມີການ log ຄ່າທີ່ເປັນ string ອອກມາ 4 ຕົວ.

ບາງຄົນກໍ່ອາດຈະຄິດວ່າເປັນຫຍັງຕ້ອງມາ run code ໂງ່ໆໃຫ້ມັນເສຍເວລາຊີວິດເບິ່ງວ່ະ? ແຕ່ກະນັ້ນລ່ະ ເຮົາກໍ່ເຫັນວ່າ function ມັນກໍ່ເຮັດວຽກຕາມປົກກະຕິຂອງມັນຕັ້ງແຕ່ເລີ່ມຕົ້ນຈົນຈົບ(ຍົກເວັ້ນໃນກໍລະນີທີ່ມີຂໍ້ຜິດພາດອີ່ຫຍັງບາງຢ່າງ)ໂດຍໃຊ້ run-to-completion ໂມເດວ, ປະເດັນຄືເຮົາບໍ່ສາມາດເຮັດໃຫ້ function ນີ້ຢຸດການເຮັດວຽກກາງຄັນໄດ້🤯.

ມາຮອດຈຸດທີ່ຟິນທີ່ສຸດແລ້ວ: generator function ຈະບໍ່ໄດ້ follow ຕາມ run-to-completion model, ນີ້ໝາຍຄວາມວ່າເຮົາສາມາດຢຸດການເຮັດວຽກຂອງ generator function ໄດ້ໃນຂະນະທີ່ມັນເຮັດວຽກຢູ່ຫວາ? ໃຈເຢັນນນ!!! ເຮົາມາເບິ່ງນຳກັນກ່ອນວ່າ generator function ແມ່ນຫຍັງ? ແລະ ເຮົາຈະຈັດການກັບມັນໄດ້ດ້ວຍວິທີໃດແດ່.

ເຮົາສາມາດຂຽນ generator function ໂດຍການຂຽນເຄື່ອງໝາຍດອກຈັນ ຫຼື ເຄື່ອງໝາຍດາວ ຫຼື ເຄື່ອງໝາຍແບ້ອີ່ຫຍັງຈັກຢ່າງທີ່ມີໜ້າຕາແບບນີ້(*) ຢູ່ທາງຫຼາຍຂອງ function keyword.

ແຕ່ນັ້ນກໍ່ບໍ່ແມ່ນທັງໝົດຂອງສິ່ງທີ່ເຮົາຕ້ອງເຮັດ, ເນື່ອງຈາກ generator function ແລະ regular function ໂດຍທົ່ວໄປແຕກຕ່າງກັນຢ່າງສິ້ນເຊີງ:

ການເອີ້ນໃຊ້ generator function ຈະທຳການ return generator object ທີ່ເປັນ iterator.
ເຮົາສາມາດໃຊ້ yield keyword ໃນ generator function ເພື່ອເຮັດໃຫ້ function ນັ້ນຢຸດການເຮັດວຽກຊົ່ວຄາວ.

ວ່າແຕ່ມັນໝາຍຄວາມວ່າຈັ່ງໃດລ່ະ?🤔.
ເຮົາມາເລີ່ມກັນຕັ້ງແຕ່ທຳອິດເລີຍຄື: ການເອີ້ນໃຊ້ generator function ຈະມີການ return generator object ອອກມາ. ແຕ່ເມື່ອເຮົາທຳການເອີ້ນໃຊ້ regular function, code ທີ່ຢູ່ໃນ function body ຈະຖືກ execute ແລະ ທຳການ return value ອອກມາປົກກະຕິ. ແຕ່ເຖິງຢ່າງໃດກໍ່ຕາມ, ເມື່ອເຮົາໄດ້ເອີ້ນໃຊ້ generator function ມັນຈະ return generator object ອອກມາ, ເຊິ່ງເມື່ອເຮົາທຳການ log value ທີ່ໄດ້ເບິ່ງຈະມີໜ້າຕາດັ່ງນີ້:

ເຊື່ອວ່າຫຼາຍໆຄົນທີ່ອ່ານມາຮອດນີ້ຄົງຈະຫຼອນສົມຄວນຢູ່, ໃນການນຳໃຊ້ຕົວຈິງມັນອາດຈະບໍ່ມີຄວາມຈຳເປັນທີ່ຈະຕ້ອງໃຊ້ properties ທັງໝົດທີ່ເຮົາເຫັນໃນ log. ດຽວເຮົາມາເບິ່ງນຳກັນຕໍ່ວ່າ generator object ມັນສາມາດນຳໃຊ້ແນວໃດໄດ້ແນ່🥶.

ທຳອິດເຮົາຈະຍ້ອນກັບໄປອີກໜ້ອຍໜຶ່ງເພື່ອທີ່ຈະຕອບຄຳຖາມທີ່ວ່າ: generator function ແຕກຕ່າງກັບ regular function ແນວໃດ?, ເຊິ່ງຄຳຕອບໃນທີ່ນີ້ກໍ່ຄົງຈະແມ່ນ: ໃນ generator function ເຮົາສາມາດໃຊ້ yeild keyword ເພື່ອຢຸດການ execution ໄດ້.

ຕົວຢ່າງ: ເຮົາສາມາດຂຽນ generator function ແບບນີ້ໄດ້.

ໃນ function ດ້ານເທິງ yield keyword ເຮັດວຽກແນວໃດ?, ການ execution ຂອງ generator ຈະຢຸດ(pause)ກໍ່ຕໍ່ເມື່ອມັນພົບ yield keyword ແລະ ຈຸດພີກຂອງການໃຊ້ generator ຄືຕອນທີ່ເຮົາເອີ້ນໃຊ້ function ຄັ້ງຕໍ່ໄປຄື ມັນຈະຈື່ວ່າຄັ້ງຫຼ້າສຸດທີ່ມັນຖືກຢຸດມັນຖືກຢຸດຢູ່ບ່ອນໃດ ແລະ ມັນສາມາດດຳເນີນການຕໍ່ຈາກຈຸດເດີມໄປໄດ້ເລີຍ😱. ມາເບິ່ງນຳກັນວ່າມັນເກີດຫຍັງຂຶ້ນຢູ່ບ່ອນນີ້ແນ່?

ຄັ້ງທຳອິດທີ່ເຮົາ run, ມັນຈະ "pauses" ໃນແຖວທຳອິດ ແລະ yields ຄ່າ '✨' ທີ່ເປັນ string.
ເມື່ອເຮົາ run ຄັ້ງທີ 2, ມັນຈະເລີ່ມຈາກແຖວທີ່ມັນຢຸດເທື່ອກ່ອນຄື yield keyword ອັນທຳອິດ. ມັນຈະ run ໄປເລື້ອຍໆຈົນຮອດ yield keyword ທີ 2 ແລະ yields ຄ່າ '💕' ທີ່ເປັນ string.
ເມື່ອເຮົາ run ຄັ້ງທີ 3, ມັນຈະເລີ່ມຈາກແຖວທີ່ມັນຢຸດໄວ້ຈາກເທື່ອກ່ອນ ຫຼື ຈາກ yield keyword ທີ 2. ເຊິ່ງມັນກໍ່ຈະເຮັດຄືເກົ່າກໍ່ຄືມັນຈະ run ໄປເລື້ອຍໆຈົນຮອດ return keyword(ເນື່ອງຈາກບໍ່ມີ yield keyword ອື່ນແລ້ວ) ແລະ ມັນຈະທຳການ return ຄ່າ Done! ອອກໄປ.

ວ່າແຕ່ເຮົາຈະເອີ້ນໃຊ້ generator function ໄດ້ແນວໃດທັງໆທີ່ເຮົາກໍ່ເຫັນແລ້ວວ່າການທີ່ເຮົາເອີ້ນໃຊ້ generator function ມັນຈະ return generator object ອອກມາ?🤔 ບ່ອນນີ້ແຫຼະທີ່ເຮົາຈະໄດ້ generator object ອອກມາຫຼິ້ນ(ບອກໄດ້ເລີຍວ່າບັນເທີງກັນທົ່ວໜ້າ🤣).

ໃນ generator object ຈະມີ next method ມາໃຫ້ນຳ(ຢູ່ໃນ prototype chain). ເຊິ່ງ method ນີ້ເຮົາຈະໃຊ້ໃນການ iterate generator object, ແຕ່ໃນການທີ່ຈະຈື່ state ຂອງຈຸດທີ່ມັນຢຸດກ່ອນໜ້ານີ້ຫຼັງຈາກທີ່ມັນ yield value, ເຮົາຕ້ອງ assign generator object ໃນຮູບແບບຂອງ variable ໃນຕົວຢ່າງເຮົາໃຊ້ຊື່ວ່າ genObj ຫຍໍ້ມາຈາກ generatorObject.

ເຮົາມາເບິ່ງກັນຕໍ່ອີກວ່າຈະເກີດຫຍັງຂຶ້ນຖ້າເຮົາເອີ້ນໃຊ້ next method ທີ່ຢູ່ໃນ genObj generator object.

generator ຈະທຳການ run ຈົນກວ່າຈະພົບກັບ yield keyword ທຳອິດ, ເຊິ່ງໃນຕົວຢ່າງມັນຈະຢູ່ແຖວທຳອິດ ມັນໄດ້ທຳການ yield object ທີ່ມີ value property ແລະ done property.

{ value: ... , done: ... }

value property ຈະເປັນ value ທີ່ເຮົາໄດ້ທຳການ yield ໄວ້.
done property ເປັນຄ່າ boolean, ທີ່ຈະເປັນຄ່າ true ກໍ່ຕໍ່ເມື່ອ generator function ໄດ້ທຳການ return value ອອກໄປແລ້ວ(ບໍ່ແມ່ນ yield)

ເຮົາໄດ້ທຳການຢຸດການ iterate ໃນ generator ທີ່ເບິ່ງຄືກັບວ່າ function ມັນຖືກ paused, ບອກເລີຍວ່າສຸດຈັກປະລັກຂິກເລີຍ. ດຽວເຮົາມາລອງເອີ້ນໃຊ້ next method ອີກຮອບລອງເບິ່ງ.

ທຳອິດເຮົາໄດ້ທຳການ log ຄ່າທີ່ເປັນ string ອອກມາເບິ່ງຈະໄດ້ First log! ຢູ່ໃນ console.log(), ແຕ່ເນື່ອງຈາກມັນບໍ່ແມ່ນ yield ຫຼື return keyword ມັນຈຶ່ງເຮັດວຽກຕໍ່ຈົນກວ່າຈະພົບ yield keyword ທີ່ໄດ້ຄ່າ '💕'. object ທີ່ໄດ້ຈາກການ yield ໂດຍ value property ຈະໄດ້ '💕' ແລະ done property, ເຊິ່ງ done property ຈະຍັງເປັນຄ່າ false ເນື່ອງຈາກ generator ຍັງບໍ່ມີການ return ເທື່ອ.

ເຮົາມາລອງໃຊ້ next method ອີກຮອບ, ໜ້າຈະເປັນຮອບສຸດທ້າຍແລ້ວມັ້ງ🤣

ເຮົາໄດ້ທຳການ log ຄ່າທີ່ເປັນ string ຈະໄດ້ Second log! ຢູ່ໃນ console.log() ຄືເກົ່າ, ຈາກນັ້ນມັນຈະພົບ return keyword ພ້ອມດ້ວຍຄ່າ 'Done!'. object ທີ່ຖືກ return ອອກມາຈະໄດ້ value property ແມ່ນ 'Done!', ມາຮອດຕອນນີ້ເຮົາໄດ້ທຳການ return ຄ່າອອກໄປແລ້ວ ດັ່ງນັ້ນ value ຂອງ done property ຈະມີຄ່າເປັນ true.

done property ຖືວ່າເປັນອີກສ່ວນທີ່ສຳຄັນທີ່ສຸດເລີຍກໍ່ວ່າໄດ້, ເຊິ່ງເຮົາສາມາດ iterate generator object ໄດ້ພຽງຄັ້ງດຽວເທົ່ານັ້ນ. ແລ້ວຖ້າສົມມຸດເຮົາເອີ້ນໃຊ້ next method ອີກຮອບມັນຈະເກີດຫຍັງຂຶ້ນ?

ຄຳຕອບກໍ່ງ່າຍໆເລີຍຄືມັນຈະທຳການ return ຄ່າ undefined ອອກມາທຸກຄັ້ງ, ແຕ່ຖ້າຕ້ອງການຢາກຈະ iterate ອີກກໍ່ພຽງສ້າງ generator object ໃໝ່.

ດັ່ງທີ່ເຮົາໄດ້ເຫັນດ້ານເທິງແລ້ວວ່າ generator function ຈະທຳການ return iterator(generator object), ແຕ່ iterator ແມ່ນຫຍັງອີກແລ້ວບາດນິ? ເອົາຄຳຕອບໄວ້ກ່ອນແລ້ວຄ່ອຍໄປເບິ່ງຕົວຢ່າງນຳກັນດ້ານລຸ່ມ. iterator ໝາຍເຖິງ object ທີ່ຖືກ return ອອກມາ ແລະ ເຮົາສາມາດໃຊ້ for of loops ແລະ spread operator ກັບ object ນັ້ນໆໄດ້.

ເຮົາລອງ spread ຄ່າທີ່ຖືກ yield ເຊິ່ງຈະເປັນຂໍ້ມູນຮູບແບບຂອງ array ໂດຍນຳໃຊ້ [... ] syntax.

ຫຼື ອາດຈະໃຊ້ for of loop

ຫຼື ອາດຈະໃຊ້ວິທີອື່ນກໍ່ໄດ້ເຊັ່ນກັນ.

ແຕ່ວ່າແມ່ນຫຍັງທີ່ເຮັດໃຫ້ iterator ເປັນ iterator?😳 ຄຳຕອບງ່າຍກໍ່ຍ້ອນວ່າເຮົາສາມາດໃຊ້ for-of loops ແລະ spread syntax ກັບ arrays, strings, maps ແລະ sets ໄດ້ນັ້ນເອງ, ສ່ວນອີກເຫດຜົນກໍ່ຍ້ອນມັນມີການ implement ສິ່ງທີ່ເອີ້ນວ່າ iterator protocol: [Symbol.iterator]. ຖ້າຍັງບໍ່ເຂົ້າໃຈ ເຮົາມາເບິ່ງຕົວຢ່າງນຳກັນດີກວ່າ.

ບັນດາ array,string ແລະ generatorObject ລ້ວນແລ້ວແຕ່ເປັນ iterators. ເຮົາລອງມາເບິ່ງ value ຂອງມັນດີກວ່າ [Symbol.iterator] property.

ແຕ່ value ຂອງ [Symbol.iterator] ທີ່ເຫັນຢູ່ໃນນັ້ນບໍ່ສາມາດ iterate ໄດ້ບໍ່? ເພື່ອຕອບຄຳຖາມນີ້ເຮົາໄປເບິ່ງຕົວຢ່າງນຳກັນເລີຍ.

ຄຳຕອບທຳອິດຄື: ແມ່ນແລ້ວ😄, ແຕ່ໃຈເຢັນກ່ອນໄອ້ສອງຢ່າຟ້າວເສຍໃຈໄປ ຄ່າຂອງມັນແຄ່ບໍ່ໄດ້ຢູ່ບ່ອນນັ້ນຊື່ໆ🤣. ດັ່ງນັ້ນຖ້າຢາກໄດ້ value ອອກມາເຮົາກໍ່ພຽງແຕ່ທຳການ add [Symbol.iterator] property ເຂົ້າໄປແບບ manual ແລະ ເຮົາຈະສາມາດ iterate ໄດ້ນັ້ນເອງ.

[Symbol.iterator] ມີການ return iterator ອອກມາ, ເຊິ່ງມັນຈະພ່ວງ next method ທີ່ຈະ return object ອອກມາຄ້າຍໆກັບຕົວຢ່າງທີ່ເຮົາເຫັນຜ່ານມາ: { value: '...', done: false/true }.

ເພື່ອຄວາມງ່າຍ, ເຮົາສາມາດ set value ຂອງ [Symbol.iterator] ໃຫ້ເທົ່າກັບ generator function ເຊິ່ງມັນຈະ return iterator ອອກມາໂດຍ default ຢູ່ແລ້ວ, ລອງສ້າງ object ທີ່ເຮົາສາມາດ iterate ໄດ້ ແລະ ທຳການ yield value ຂອງ object ທັງໝົດ.

ສັງເກດເບິ່ງວ່າຈະເກີດຫຍັງຂຶ້ນຖ້າຫາກເຮົາໃຊ້ spread syntax ຫຼື for-of loop ກັບ object ທີ່ເຮົາໄດ້ມາ

ຫຼືເຮົາອາດຈະຕ້ອງການພຽງແຕ່ object keys, ຖ້າແບບນີ້ກໍ່ງ່າຍໆເລີຍ ເຮົາພຽງທຳການ yield Object.keys(this) ແທນ this

ມາເບິ່ງຜົນລັບນຳກັນ

Object.keys(this) ເປັນ array, ດັ່ງນັ້ນ value ທີ່ຖືກ yield ຈະໄດ້ເປັນ array ຈາກນັ້ນເຮົາຈະ spread array ທີ່ເຮົາໄດ້ມາໄປເປັນ array ອື່ນໆ ສິ່ງທີ່ຈະເກີດຂຶ້ນກໍ່ຄືເຮົາຈະໄດ້ nested array ມາແທນ. ເຮົາບໍ່ໄດ້ຕ້ອງການ array ແບບນີ້, ເຮົາພຽງຕ້ອງການ yield ແຕ່ລະ key ເທົ່ານັ້ນ.

ເຮົາສາມາດ yield value ຈາກ iterator ຢູ່ໃນ generator ໄດ້ໂດຍໃຊ້ yield* keyword, ສົມມຸດວ່າເຮົາມີ generator function ທີ່ yield ທຳອິດຈະ yield "🥑" ຕໍ່ມາເຮົາມີການ yield values ມາຈາກ iterator(ໃນຕົວຢ່າງນີ້ເຮົາຈະໃຊ້ເປັນ array) ເຊິ່ງໃນກໍລະນີນີ້ເຮົາໄດ້ໃຊ້ yield* keyword, ຈາກນັ້ນເຮົາໄດ້ທຳການແທນຄ່າດ້ວຍ generator ອື່ນ.

ແຕ່ລະ value ຂອງ generator ທີ່ໄດ້ແທນຄ່າຈະຖືກ yield ກ່ອນທີ່ມັນຈະທຳການ iterate genObj iterator ຕໍ່ໄປ.

ນີ້ຄືສິ່ງທີ່ເຮົາຕ້ອງເຮັດໃນກໍລະນີທີ່ເຮົາຕ້ອງການ object keys ທັງໝົດ

ສຳລັບການນຳໃຊ້ generator function ອີກແບບໜຶ່ງກໍ່ຄື: ເຮົາສາມາດໃຊ້ເປັນ observer functions ໄດ້, ເນື່ອງຈາກ generator ສາມາດລໍຖ້າ incoming data ແລະ ເມື່ອມີ data ຖືກສົ່ງຜ່ານເຂົ້າມາເທົ່ານັ້ນມັນຈຶ່ງຈະທຳການ process. ເບິ່ງຕົວຢ່າງດ້ານລຸ່ມ🧐

ສິ່ງໜຶ່ງທີ່ຕ່າງກັນຢ່າງຊັດເຈນເລີຍໃນທີ່ນີ້ແມ່ນເຮົາບໍ່ໄດ້ມີພຽງ yield [value] ຄືກັບທີ່ເຮົາເຫັນໃນຕົວຢ່າງທີ່ຜ່ານມາ, ແຕ່ເຮົາໄດ້ assign ຄ່າໄວ້ໃນຕົວປ່ຽນທີ່ຊື່ວ່າ second ແລະ ມີການ yield value ທີ່ເປັນ string ເຊິ່ງມີຄ່າ First!, ເຊິ່ງ value ນີ້ເອງຈະຖືກ yield ໃນຄັ້ງທຳອິດທີ່ເຮົາເອີ້ນໃຊ້ next method.

ມາເບິ່ງວ່າຈະເກີດຫຍັງຂຶ້ນເມື່ອເຮົາເອີ້ນໃຊ້ next method ຄັ້ງທຳອິດ.

ເມື່ອມັນພໍ້ yield ໃນແຖວທຳອິດ ແລະ ມັນໄດ້ທຳການ yield value First!, ດັ່ງນັ້ນ value ຂອງຕົວປ່ຽນ second ຈະມີຄ່າແນວໃດ?

ແນ່ນອນວ່າມັນຈະເປັນ value ທີ່ເຮົາສົ່ງໄປໃນ next method ທີ່ເຮົາເອີ້ນໃຊ້ໃນຄັ້ງຕໍ່ໄປ, ເຮົາມາລອງສົ່ງ value ທີ່ເປັນ string ດັ່ງນີ້ 'I like JavaScript' ເຂົ້າໄປໃນ next method.

ສິ່ງທີ່ສຳຄັນທີ່ຕ້ອງສັງເກດໃນທີ່ນີ້ຄື: ເບິ່ງວ່າການເອີ້ນໃຊ້ next method ຍັງບໍ່ໄດ້ມີການ track input ໃດໆເທື່ອ ເຮົາພຽງ start observer ໂດຍການເອີ້ນໃຊ້ໃນຄັ້ງທຳອິດ. generator ຈະລໍຖ້າ input ຈາກເຮົາກ່ອນທີ່ມັນຈະສືບຕໍ່ການເຮັດວຽກຂອງມັນຕໍ່ໄປ ແລະ ອາດຈະປະມວນຜົນຄ່າທີ່ເຮົາສົ່ງໄປໃນ next method.

ເປັນຫຍັງເຮົາຈຶ່ງຕ້ອງໃຊ້ generator function?

ຂໍ້ດີຢ່າງໜຶ່ງຂອງການໃຊ້ generator ຄືຄວາມຈິງທີ່ວ່າມັນເປັນ lazily evaluated, ໝາຍຄວາມວ່າ value ທີ່ຖືກ return ຫຼັງຈາກທີ່ມີການເອີ້ນໃຊ້ next method ຈະຖືກ compute ຫຼັງຈາກທີ່ເຮົາຮ້ອງຂໍເທົ່ານັ້ນ(ປະມານວ່າສັ່ງໃຫ້ເຮັດຈຶ່ງເຮັດ🫡). fucntion ປົກກະຕິຈະບໍ່ມີແບບນີ້ - value ທັງໝົດຈະຖືກ generate ໃຫ້ເຮົາໃນກໍລະນີທີ່ເຮົາຈຳເປັນຕ້ອງໃຊ້ໃນອານາຄົດ.

ເທົ່າທີ່ຜ່ານມາມັນກໍ່ເບິ່ງຄືກັບ use cases ອື່ນໆ, ແຕ່ມັນຈະຊ່ວຍໃຫ້ເຮົາມີທາງເລືອກທີ່ຈະສາມາດ control ການ iterate datasets ທີ່ໃຫຍ່ໆໄດ້.

ລອງຈິນຕະນາການເບິ່ງວ່າເຮົາມີ list ຂອງ book clubs📚, ເພື່ອໃຫ້ຕົວຢ່າງຂອງເຮົາງ່າຍ ແລະ ສັ້ນເຮົາຈຶ່ງມີ data ດັ່ງນີ້: ແຕ່ລະ book clubs ຈະມີ member ພຽງ 1 ຄົນ ແລະ ອ່ານປື້ມຫຼາຍຫົວທີ່ສະແດງໃນ books array.

ຕອນນີ້ເຮົາຕ້ອງການທີ່ຈະຫາ book ທີ່ມີ id ເທົ່າກັບ ey812, ໃນການຄົ້ນຫາເຮົາອາດຈະໃຊ້ nested for-loop ຫຼື forEach helper, ແຕ່ນັ້ນກໍ່ໝາຍຄວາມວ່າເຮົາຍັງຄົງສາມາດ iterate data ໄດ້ເຖິງແມ່ນວ່າເຮົາຈະພົບຂໍ້ມູນທີ່ເຮົາຕ້ອງການແລ້ວກໍ່ຕາມ.
ສິ່ງທີ່ຄັກກ່ຽວກັບ generator ໃນທີ່ນີ້ຄື: ມັນຈະບໍ່ເຮັດວຽກໄປເລື້ອຍໆຈົນກວ່າເຮົາຈະບອກໃຫ້ມັນເຮັດ-ໝາຍຄວາມວ່າເຮົາສາມາດປະເມີນ item ທີ່ຖືກ return ອອກມາໄດ້ ແລະ ຖ້າມັນເປັນ item ທີ່ເຮົາຕ້ອງການ ເຮົາກໍ່ບໍ່ຈຳເປັນທີ່ຈະຕ້ອງເອີ້ນໃຊ້ next method. ເຮົາລອງມາເບິ່ງນຳກັນວ່າຈະເປັນແນວໃດ.

ທຳອິດເຮົາຈະທຳການສ້າງ generator ທີ່ມີການ iterate books array ຂອງແຕ່ລະ team member, ເຮົາຈະສົ່ງຄ່າ books array ຂອງ team member ເຂົ້າໄປໃນ function ຈາກນັ້ນຈະມີການ iterate array ແລະ ທຳການ yield ແຕ່ລະ book

ຫຼັງຈາກທີ່ເຮົາໄດ້ generator ດ້ານເທິງມາແລ້ວ, ຕໍ່ໄປເຮົາຕ້ອງໄດ້ສ້າງອີກ generator ທີ່ iterate clubMembers array. ເຊິ່ງໃນຈຸດນີ້ເຮົາບໍ່ໄດ້ສົນໃຈຂໍ້ມູນຂອງ member ເນື່ອງຈາກເຮົາຕ້ອງການທີ່ຈະ iterate ຂໍ້ມູນຂອງ books ເທົ່ານັ້ນ. ຢູ່ໃນ iterateMembers generator ເຮົາໄດ້ທຳການ yield iterateBooks ໂດຍການສົ່ງ books ຂອງ member ເຂົ້າໄປ.

ມາຮອດຂັ້ນຕອນສຸດທ້າຍເຮົາຈະທຳການ iterate bookclubs, ເຊິ່ງມັນກໍ່ຄືກັບຕົວຢ່າງທີ່ຜ່ານມາ ເຮົາບໍ່ໄດ້ສົນໃຈຂໍ້ມູນຂອງ bookclubs, ແຕ່ເຮົາສົນໃຈພຽງ club members(ສະເພາະ books ຂອງແຕ່ລະ member). ເຮົາຈະທຳການ yield iterateMembers ແລະ ທຳການສົ່ງ clubMembers array ເຂົ້າໄປ.

ເພື່ອທີ່ຈະ iterate ທັງໝົດທີ່ຂຽນມາ, ເຮົາຕ້ອງການ generator object ທີ່ iterable ໂດຍການສົ່ງ bookClub array ເຂົ້າໄປໃນ iterateBookClubs generator, ຈາກນັ້ນເຮົາຈະທຳການເອີ້ນໃຊ້ໂດຍການສ້າງຕົວປ່ຽນ it ຂຶ້ນມາເພື່ອເປັນ iterator.

ຫຼັງຈາກຜ່ານຂັ້ນຕອນທຸກຢ່າງມາແລ້ວເຮົາຈະທຳການເອີ້ນໃຊ້ next method ຈົນກວ່າເຮົາຈະໄດ້ຂໍ້ມູນຂອງ book ໂດຍທີ່ id ຂອງ book ຕ້ອງເທົ່າກັບ ey812.

ຕອນນີ້ເຮົາບໍ່ຈຳເປັນຕ້ອງ iterate data ທັງໝົດເພື່ອເອົາຂໍ້ມູນຂອງ book, ແຕ່ເຮົາພຽງຫາຂໍ້ມູນເທົ່າທີ່ເຮົາຕ້ອງການຕົວຈິງແທນ. ສ່ວນການເອີ້ນໃຊ້ next method ດ້ວຍຕົວເອງນັ້ນອາດຈະເປັນເລື່ອງທີ່ຂັດຫູຂັດຕາໄປແນ່, ດັ່ງນັ້ນເຮົາຈຶ່ງຕ້ອງໄດ້ສ້າງ function ໃນການເອີ້ນໃຊ້ next method ຈົນກວ່າເຮົາຈະໄດ້ຂໍ້ມູນຕາມທີ່ເຮົາຕ້ອງການ.
ເຮົາຈະທຳການສົ່ງ id ຂອງ book ເຂົ້າໄປໃນ findBook function ເພື່ອທຳການຄົ້ນຫາ book ຕາມ id ທີ່ເຮົາສົ່ງເຂົ້າໄປ, ຖ້າພົບວ່າ id(ທີ່ສົ່ງເຂົ້າໄປ) ແລະ value.id ຕົງກັນມັນກໍ່ຈະທຳການໂຍນ value ອອກມາ, ແຕ່ຖ້າທັງ 2 id ບໍ່ຕົງກັນມັນກໍ່ຈະທຳການເອີ້ນໃຊ້ next method ອີກຄັ້ງແທນ.

ແນ່ນອນວ່າໃນຕົວຢ່າງທີ່ຍົກມາມັນຍັງເປັນຂໍ້ມູນທີ່ໜ້ອຍ, ແຕ່ລອງຄິດພາບເບິ່ງວ່າເຮົາມີ data ທີ່ຫຼາຍແຮງ ຫຼື ອາດຈະເປັນຂໍ້ມູນທີ່ຖືກ stream ເຂົ້າມາແລ້ວເຮົາຕ້ອງການທີ່ຈະແປງຂໍ້ມູນເຫຼົ່ານັ້ນ ຫຼື ອາດຈະຕ້ອງການຫາຂໍ້ມູນພຽງຢ່າງດຽວຈາກ datasets ໃຫຍ່ໆ. ໂດຍປົກກະຕິເຮົາຕ້ອງໄດ້ຖ້າໃຫ້ dataset ຂອງເຮົາພ້ອມກ່ອນເຮົາຈຶ່ງຈະເລີ່ມການແປງຂໍ້ມູນເຫຼົ່ານັ້ນໄດ້. ແຕ່ຖ້າໃຊ້ generator function ເຮົາສາມາດຂໍຂໍ້ມູນພຽງໜ້ອຍດຽວ, ກວດສອບຂໍ້ມູນ ແລະ value ຈະຖືກ generate ກໍ່ຕໍ່ເມື່ອເຮົາທຳການເອີ້ນໃຊ້ next method ເທົ່ານັ້ນ.

ອ້າງອີງ: 💡🎁 JavaScript Visualized: Generators and Iterators

JavaScript EP5: Prototypal Inheritance🤰🏻👨‍👩‍👧‍👦

phatsss — Mon, 10 Apr 2023 09:27:32 +0000

ຕອນທີ່ເຮົາຂຽນ JavaScript ເຊື່ອວ່າທຸກຄົນກໍ່ລ້ວນແລ້ວແຕ່ເຄີຍໃຊ້ບັນດາ built-in methods ກັນທັງນັ້ນເຊັ່ນ: .length, .split(), .join(), etc. ບໍ່ວ່າຈະເປັນການໃຊ້ເພື່ອຈຸດປະສົງໃດໆ ຫຼື ໃຊ້ກັບປະເພດຂໍ້ມູນໃດໆກໍ່ຕາມເຊັ່ນ: string,array, object. ແຕ່ຫຼາຍໆຄົນກໍ່ອາດຈະບໍ່ສົງໄສເລີຍວ່າບັນດາ methods ເຫຼົ່ານັ້ນມັນມາຈາກໄສ? ຢ່າບອກໃດວ່າມັນຄືເວດມົນ 🪄🤣. ອັນທີ່ຈິງຖ້າຈະໃຫ້ຕອບຄຳຖາມດ້ານເທິງແບບສັ້ນໆເລີຍ ຄຳຕອບກໍ່ຈະໄດ້ປະມານວ່າ: ຍ້ອນອີ່ຫຍັງບາງຢ່າງທີ່ເອີ້ນວ່າ prototypal inheritance. ແຕ່ເຊື່ອບໍ່ວ່າໃນຕອນທີ່ຂຽນ code ເຮົາໃຊ້ມັນຫຼາຍກວ່າທີ່ຄິດອີກ, ສະນັ້ນເຮົາມາສຶກສາໃຫ້ເຂົ້າໃຈກ່ຽວກັບ prototypal inheritance ໃຫ້ຫຼາຍຂຶ້ນນຳກັນ.

ສົມມຸດວ່າເຮົາມີເວັບທີ່ໃຫ້ຄົນທົ່ວໄປສາມາດເຂົ້າໄປເບິ່ງຂໍ້ມູນຂອງໝາໄດ້, ເຮົາມັກຈະຕ້ອງໄດ້ສ້າງ object ຫຼາຍໆອັນທີ່ເປັນ type ດຽວກັນ.

ສຳລັບຂໍ້ມູນຂອງໝາ, ເຮົາຕ້ອງການ object ທີ່ເປັນຕົວແທນຂອງຂໍ້ມູນໝາໂຕນັ້ນ. ແທນທີ່ເຮົາຈະຂຽນ object ໃໝ່ທຸກໆຄັ້ງ ໃນທີ່ນີ້ເຮົາຈະໃຊ້ constructor function(ຮູ້ແຫຼະວ່າພາກັນຄິດຫຍັງຢູ່, ເລື່ອງຂອງ class ດຽວເຮົາຈະມາເວົ້າກັນອີກຕື່ມພາຍຫຼັງ)ເຊິ່ງເຮົາກໍ່ສາມາດສ້າງ instance ຂອງ Dog ໄດ້ດ້ວຍ keyword ໃໝ່ໄດ້ເຊັ່ນກັນ.

ໝາທຸກໆໂຕຂອງເຮົາຈະມີຂໍ້ມູນດັ່ງນີ້: name, breed, color ແລະ function ທີ່ບອກວ່າໝາເຫົ່າຫຼືບໍ່ຄື bark🐕.

ເມື່ອເຮົາສ້າງ Dog constructor function ສຳເລັດ, ມັນບໍ່ແມ່ນ object ດຽວທີ່ເຮົາຈະສ້າງ, ມັນຍັງມີ object ອື່ນທີ່ຖືກສ້າງໂດຍອັດຕະໂນມັດຄື: prototype. ໂດຍ default ແລ້ວ object ນີ້ບັນຈຸ constructor property ທີ່ອ້າງອີງເຖິງ original constructor function, ເຊິ່ງໃນກໍລະນີນີ້ແມ່ນ Dog.

prototype property ໃນ Dog constructor function ເປັນ non-enumerable(ນັບບໍ່ໄດ້) ໝາຍຄວາມວ່າມັນຈະບໍ່ສະແດງເມື່ອເຮົາ access ເຂົ້າ objects properties, ແຕ່ມັນຍັງມີຢູ່.

ແລ້ວເປັນຫຍັງເຮົາຈຶ່ງມີ property object?, ກ່ອນອື່ນເຮົາມາສ້າງ dogs ຈັກໂຕສອງໂຕທີ່ເຮົາຕ້ອງການສະແດງ. ເພື່ອໃຫ້ເຂົ້າໃຈງ່າຍ, ເຮົາຈະສ້າງ dog1 ແລະ dog2 ເຊິ່ງ dog1 ມີຊື່ວ່າ Daisy ເປັນພັນລາບາດໍ ສີດຳສຸດໜ້າຮັກ ແລະ dog2 ຊື່ວ່າ Jack ເປັນພັນ ແຈັກຣັດເຊວ ສີຂາວທີ່ກ້າຫານພ້ອມບວກກັບທຸກຢ່າງ.

ເມື່ອເຮົາລອງ log ເບິ່ງ dog1 ຜ່ານ console ແລະ expand properties ຂອງມັນອອກມາເບິ່ງຈະໄດ້ດັ່ງນີ້:

ເຮົາຈະເຫັນ properties ທີ່ເຮົາໄດ້ເພີ່ມເຂົ້າເຊັ່ນ: name, breed, color ແລະ bark. ແຕ່ໆໆໆ ເຫັນຫຍັງບໍ່? ໄອ້ property __proto__ ຄືແບ້ອີ່ຫຍັງອີກລ່ະບາດນິ?🤯 ມັນ non-enumerable(ນັບບໍ່ໄດ້), ເຊິ່ງມັນກໍ່ໝາຍຄວາມວ່າໂດຍປົກກະຕິມັນຈະບໍ່ສະແດງເມື່ອເຮົາ get properties ໃນ object, ດຽວເຮົາມາຂະຫຍາຍຄວາມຈຸດນີ້ນຳກັນ.

ັມັນຄ້າຍຄືກັບ Dog.prototype object ເລີຍ, ແຕ່ເຮົາລອງເດົາເບິ່ງວ່າ __proto__ ແມ່ນເປັນການອ້າງອີງ Dog.prototype object🤔. ແຕ່ເຊື່ອບໍ່ວ່ານີ້ແມ່ນ prototypal inheritance - ແຕ່ລະ instance ຂອງ constructor ສາມາດເຂົ້າເຖິງ prototype ຂອງ constructor ໄດ້🥶.

ແລ້ວມັນຄັກບ່ອນໃດ?🫣, ບາງເທື່ອເຮົາກໍ່ມີ properties ທີ່ instance ທັງໝົດໃຊ້ຮ່ວມກັນ. ຕົວຢ່າງໃນກໍລະນີນີ້ແມ່ນ bark function, ເຊິ່ງທຸກໆ instance ແມ່ນມີຄືກັນທັງໝົດ ແລ້ວເປັນຫຍັງເຮົາຈຶ່ງຕ້ອງມາສ້າງ function ໃໝ່ທຸກຄັ້ງທີ່ເຮົາສ້າງ dog ແຖມຍັງໃຊ້ memory ໃນແຕ່ລະຄັ້ງອີກ? ທັງໆທີ່ເຮົາສາມາດເພີ່ມ function ນີ້ລົງໄປໃນ Dog.prototype object ໄດ້ເລີຍ😂.

ເມື່ອເຮົາພະຍາຍາມທີ່ຈະ access property ໃນ instance ທຳອິດ engine ຈະຄົ້ນຫາຢູ່ local ເພື່ອເບິ່ງວ່າ property ໄດ້ຖືກ defined ໃນ object ເອງຫຼືບໍ່?. ແຕ່ຢ່າງໃດກໍ່ຕາມ ຖ້າມັນບໍ່ພົບ property ທີ່ເຮົາຕ້ອງການ access ນັ້ນ, engine ຈະທຳການເຂົ້າໄປເບິ່ງຢູ່ prototype ຜ່ານ __proto__ property.

ຕອນນີ້ມັນເປັນພຽງຂັ້ນຕອນດຽວ, ແຕ່ມັນຍັງມີອີກຫຼາຍຂັ້ນຕອນຕື່ມອີກ. ຖ້າຫາກ follow ຕາມຕົວຢ່າງທີ່ຜ່ານມາຈະສັງເກດເຫັນວ່າເຮົາບໍ່ໄດ້ເພີ່ມ property 1 ລາຍການ, ເມື່ອເຮົາ expand __proto__ object ທີ່ສະແດງ Dog.prototype. Dog.prototype ເປັນ object ໝາຍຄວາມວ່າທີ່ຈິງແລ້ວມັນເປັນ instance ຂອງ Object constructor ສະແດງວ່າ Dog.prototype ກໍ່ມີ __proto__ property, ເຊິ່ງເປັນການອ້າງອີງເຖິງ Object.prototype.

ໃນທີ່ສຸດເຮົາກໍ່ໄດ້ຄຳຕອບແລ້ວວ່າບັນດາ built-in methods ມາຈາກໄສ, ມາຢູ່ໃນ prototype chain ນັ້ນເອງ🤩. ຖ້າໃຜຍັງບໍ່ໄດ້ຄຳຕອບກັບໄປອ່ານອີກຮອບເດີ 5555.

ຕົວຢ່າງ: .toString() method. ມັນຖືກ defined ຢູ່ local ໃນ dog1 object ບໍ່? ເທົ່າທີ່ເຫັນກະບໍ່ໃດລ່ະ😂 ຫຼື ມັນຖືກ defined ຢູ່ໃນ object dog1.__proto__ ແລ້ວມັນມີການອ້າງອີງເຖິງ Dog.prototype ບໍ່? ບໍ່ໜ້າຈະແມ່ນເຊັ່ນກັນ, ແຕ່ມັນຖືກ defined ຢູ່ໃນ Dog.prototype.__proto__ ທີ່ອ້າງອີງເຖິງ Object.prototype ພີ້ນ່ະ🤣.

ຕອນນີ້ເຮົາຫາກໍ່ໄດ້ໃຊ້ constructor functions (function Dog() { ... }) ທີ່ຍັງເປັນວິທີຂຽນທີ່ຖືກຕ້ອງຢູ່ໃນພາສາ JavaScript, ແຕ່ມີວິທີທີ່ງ່າຍກວ່ານັ້ນໃນການໃຊ້ constructor functions ທີ່ເຮັດວຽກຮ່ວມກັນກັບ prototypes ຄື: classes.

ການໃຊ້ classes ເປັນພຽງການປ່ຽນວິທີຂຽນເພື່ອໃຫ້ເຮົາໃຊ້ constructor functions ໄດ້ກະທັດຮັດ ແລະ ເຂົ້າໃຈງ່າຍຂຶ້ນເທົ່ານັ້ນ, ເຊິ່ງທຸກຢ່າງຍັງຄົງເຮັດວຽກປົກກະຕິ.

ເຮົາຂຽນ classes ດ້ວຍ class keyword. ໂດຍພື້ນຖານ class ຈະມີ constructor function, ບັນດາ properties ທີ່ເຮົາຕ້ອງການເພີ່ມໃນ prototype ແມ່ນຖືກ defined ຢູ່ໃນ body ຂອງ classes.

ອີກຂໍ້ດີຂອງການໃຊ້ class ກໍ່ຄືເຮົາສາມາດ extend classes ອື່ນໆໄດ້.

ເຮົາຕ້ອງການສະແດງໝາສາຍພັນຊິວາວາຫຼາຍໆໂຕ, ເພື່ອໃຫ້ຕົວຢ່າງຂອງເຮົາເຂົ້າໃຈງ່າຍ ເຮົາຈະສົ່ງ property name ໄປ Dog class ແທນ name,breed ແລະ color. ແຕ່ວ່າຊິວາວາຍັງຄົງມີສະກິວພິເສດຢູ່ຄື: ມັນເຫົ່າເກັ່ງແຖມຍັງສຽງແຫຼມໆນ້ອຍໆອີກ🤣 ແທນທີ່ມັນຈະເຫົ່າແບບດຸດັນເຣົ້າໃຈ(Woof), ຖ້າເປັນຊິວາວາອາດຈະເປັນ small woof.

ໃນ extended class ເຮົາສາມາດ access ເຂົ້າໄປ parent class' constructor ໂດຍໃຊ້ super keyword. ສ່ວນບັນດາ arguments ທີ່ parent class' constructor ຕ້ອງການ ເຮົາຕ້ອງສົ່ງຄ່າໄປ super, ເຊິ່ງໃນກໍລະນີນີ້ແມ່ນ name.

myPet ສາມາດ access ເຂົ້າໄດ້ທັງ Chihuahua.prototype ແລະ Dog.prototype (ແລະ Object.prototype ໂດຍອັດຕະໂນມັດ, ເນື່ອງຈາກ Dog.prototype ເປັນ object).

ເນື່ອງຈາກ Chihuahua.prototype ມີ smallBark function ແລະ Dog.prototype ມີ bark function ເຮົາຈຶ່ງສາມາດ access ໄດ້ທັງ smallBark ແລະ bark ໃນ myPet.

ເຮົາລອງຈິນຕະນາການເບິ່ງວ່າ prototype chain ບໍ່ໄດ້ access ໄປໄດ້ຕະຫຼອດ. ຖ້າຫາກວ່າມີ object ທີ່ເປັນ prototype ເທົ່າກັບຄ່າ null, ໃນກໍລະນີນີ້ແມ່ນ Object.prototype object ຖ້າເຮົາພະຍາຍາມ access property ທີ່ມັນບໍ່ພົບຢູ່ local ຫຼື prototype chain ມັນຈະ return ຄ່າ undefined.

ເຖິງແມ່ນວ່າໃນບົດຄວາມນີ້ໄດ້ອະທິບາຍທຸກຢ່າງກ່ຽວກັບການໃຊ້ constructor functions ແລະ classes ໄປແລ້ວ, ແຕ່ມັນກໍ່ຍັງມີອີກວິທີອື່ນເຊັ່ນກັນໃນການທີ່ຈະເພີ່ມ prototypes ໃນ objects ເຊັ່ນ: Object.create method, ເຊິ່ງ method ນີ້ເຮົາສາມາດສ້າງ object ໃໝ່ ແລະ ສາມາດລະບຸໄດ້ເລີຍວ່າ prototype ຂອງ object ເຮົາຈະມີໜ້າຕາແບບໃດ.

ວິທີການແມ່ນເຮົາຈະທຳການສົ່ງ object ໃນຮູບແບບຂອງ argument ໄປ Object.create method, object ທີ່ເຮົາສົ່ງເຂົ້າໄປຈະເປັນ prototype ຂອງ object ທີ່ເຮົາສ້າງ.

ເຮົາມາລອງ log ເບິ່ງ object ທີ່ເຮົາຫາກໍ່ສ້າງລອງເບິ່ງ:

ເຮົາບໍ່ໄດ້ທຳການເພີ່ມ properties ໃດໆເຂົ້າໄປໃນ me opbject, ມັນມີພຽງ __proto__ property ທີ່ non-enumerable(ບໍ່ສາມາດນັບໄດ້)ເທົ່ານັ້ນ. __proto__ property ມີການອ້າງອີງໄປຍັງ object ທີ່ເຮົາໄດ້ທຳການ defined ໃຫ້ເປັນ prototype. person object ທີ່ມີ name ແລະ age ເປັນ property, ເນື່ອງຈາກ person object ເປັນ object ເຊິ່ງ value ຂອງ __proto__ property ໃນ person object ແມ່ນ Object.prototype.

ອ້າງອີງ: 🎉👨‍👩‍👧‍👧 JavaScript Visualized: Prototypal Inheritance

JavaScript EP4: JavaScript Engine 🛠️⚙️

phatsss — Thu, 06 Apr 2023 17:03:21 +0000

ໃນ EP ນີ້ເຮົາຈະມາເວົ້າເຖິງ JS Engine ວ່າມັນເຮັດວຽກຈັ່ງໃດ, ເພື່ອໃຫ້ເຮົາເຫັນພາບຂະບວນການເບື້ອງຫຼັງຂອງ JS ຫຼາຍຂຶ້ນ. ເຮົາເຄີຍສົງໄສບໍ່ວ່າບັນດາ machine ມັນເຂົ້າໃຈ code ທີ່ເຮົາຂຽນໄດ້ຈັ່ງໃດ?. JavaScript Developer ບໍ່ຈຳເປັນຕ້ອງຈັດການກັບ compilers ດ້ວຍຕົວເອງ, ເຊິ່ງນັກພັດທະນາມືໃໝ່ຫຼາຍໆຄົນກໍ່ບໍ່ໄດ້ສົນໃຈເລື່ອງນີ້ເລີຍ ແຕ່ມັນຍິ່ງເປັນການດີຖ້າເຮົາຈະສຶກສາ ແລະ ມີຄວາມຮູ້ພື້ນຖານກ່ຽວກັບ JavaScript Engine ແລະ ເບິ່ງວ່າມັນຈະຈັດການກັບ code ທີ່ເປັນ human-friendly ແລະ ປ່ຽນເປັນສິ່ງທີ່ machine ເຂົ້າໃຈ🚀.

ຕົວຢ່າງທີ່ໃຊ້ໃນບົດຄວາມນີ້ແມ່ນໃຊ້ NodeJS ທີ່ based on the V8 Engine ແລະ ໃຊ້ Browser ທີ່ເປັນ Chromium-based.

HTML parser ຈະພົບ script tag(<script></script>)ທີ່ມີການລະບຸ JS source(ອາດຈະຢູ່ໃນ script tag ຫຼື import ມາຈາກໄຟລ໌ນອກກໍ່ໄດ້). code ທີ່ຢູ່ໃນນັ້ນຈະຖືກ load ຈາກທຸກແຫຼ່ງທີ່ມາເຊັ່ນ: network,cache ແລະ service worker ທີ່ຖືກຕິດຕັ້ງໄວ້ແລ້ວ. response ທີ່ໄດ້ຈາກ requested script ແມ່ນຈະຢູ່ໃນຮູບແບບ stream of bytes ທີ່ຈະມີ byte stream decoder ເຮັດໜ້າທີ່ໃນການຖອດລະຫັດ stream of bytes ຫຼັງຈາກມັນໂຫຼດສຳເລັດ.

byte stream decoder ຈະທຳການສ້າງ token ຂຶ້ນມາຫຼັງຈາກທີ່ທຳການຖອດລະຫັດ stream of bytes ສຳເລັດ. ຕົວຢ່າງ, 0066 ທຳການ decode ໄດ້ f, 0075 ໄດ້ u, 006e ໄດ້ n, 0063 ໄດ້ c, 0074 ໄດ້ t, 0069 ໄດ້ i, 006f ໄດ້ o, ແລະ 006e ໄດ້ n ຕາມດ້ວຍ white space. ເບິ່ງຄືກັບວ່າເຮົາຂຽນ function ເຊິ່ງຄຳນີ້ກໍ່ເປັນ reserved keyword ຢູ່ໃນ JavaScript, ເຊິ່ງມັນຈະສ້າງ token ຂຶ້ນມາ ແລະ ສົ່ງໄປທີ່ parser(ແລະ pre-parser, ຈະອະທິບາຍພາຍຫຼັງ). ຂະບວນການທີ່ຍົກຕົວຢ່າງມາແມ່ນຈະເກີດຂຶ້ນກັບ byte stream ທີ່ເຫຼືອເຊັ່ນກັນ.

ຕົວ engine ຈະໃຊ້ parser 2 ຕົວຄື: pre-parser ແລະ parser. ເພື່ອຫຼຸດເວລາໃນການໂຫຼດໜ້າເວັບ, engine ຈະພະຍາຍາມຫຼີກລ່ຽງການ parsing code ທີ່ບໍ່ຈຳເປັນໃຫ້. pre-parser ຈະ handles code ທີ່ອາດຈະໄດ້ໃຊ້ໄວ້ ໃນຂະນະທີ່ຕົວ parser ຈະ handles code ທີ່ຈຳເປັນ. ຖ້າຫາກ function ບາງຢ່າງຖືກເອີ້ນໃຊ້ຫຼັງຈາກທີ່ user ກົດປຸ່ມ, ມັນກໍ່ບໍ່ຈຳເປັນທີ່ code ຈະຖືກ compile ໃນທັນທີພຽງເພື່ອໂຫຼດໜ້າເວັບຢ່າງດຽວ. ແຕ່ຖ້າຫາກ user ກົດປຸ່ມ ແລະ ມີການ require code ບາງສ່ວນ, ມັນຈະຖືກສົ່ງໄປ parser.

Parser ຈະທຳການສ້າງ node ຕາມ token ທີ່ໄດ້ຮັບຈາກ byte stream decoder, ຈາກນັ້ນມັນຈະສ້າງ Abstract Syntax Tree ຫຼື AST ດ້ວຍ node ເຫຼົ່ານັ້ນ 🌲🌳.

ຕໍ່ມາຈະເປັນໜ້າທີ່ຂອງ interpreter, ເຊິ່ງ interpreter ຈະດຳເນີນການຜ່ານ AST ແລະ ທຳການສ້າງ byte code ໂດຍອີງຕາມຂໍ້ມູນທີ່ AST ມີ. ເມື່ອ byte code ຖືກສ້າງສຳເລັດແລ້ວ, AST ຈະຖືກລຶບ ແລະ ລ້າງພື້ນທີ່ໜ່ວຍຄວາມຈຳ(memory space) ຫຼັງຈາກນັ້ນເຮົາກໍ່ມີ byte code ທີ່ machine ເຂົ້າໃຈແລ້ວ 🚀.

ເຖິງ byte code ຈະໄວຢູ່ກໍ່ຕາມ, ແຕ່ມັນຍັງໄວກວ່ານີ້ໄດ້ອີກ. ໃນຂະນະທີ່ byte code ນີ້ເຮັດວຽກ, ຂໍ້ມູນຕ່າງໆຈະຖືກ generate ຂຶ້ນ, ເຊິ່ງມັນຈະສາມາດ detect ໄດ້ວ່າພຶດຕິກຳໃດເກີດຂຶ້ນເລື້ອຍໆ ແລະ ປະເພດຂອງ data ຈະຖືກນຳມາໃຊ້. ບາງເທື່ອເຮົາກໍ່ເອີ້ນໃຊ້ function ເປັນສິບໆຮອບ, ເຊິ່ງໃນຈຸດນີ້ເຮົາຈະທຳການ optimize ເພື່ອໃຫ້ມັນເຮັດວຽກໄດ້ໄວ້ຂຶ້ນ.
byte code ແລະ type feedback ທີ່ຖືກ generate ຂຶ້ນແມ່ນຈະຖືກສົ່ງໄປ optimizing compiler ພ້ອມໆກັນ. optimizing compiler ຈະນຳທັງ 2 ຢ່າງນັ້ນມາທຳການ optimized ແລະ generate ອອກມາເປັນ machine code.

JavaScript ເປັນ dynamic type language, ໝາຍຄວາມວ່າ type ຂອງ data ສາມາດປ່ຽນແປງໄດ້ຕະຫຼອດເວລາ. ຖ້າຫາກ JS Engine ຕ້ອງກວດສອບ data type ຢູ່ຕະຫຼອດເວລາ(ແຕ່ໃນຂະບວນການພັດທະນາ, ການໃຊ້ data type ແມ່ນຈະເຮັດໃຫ້ການພັດທະນາມີປະສິດທິພາບຫຼາຍ-ແນະນຳໄປເບິ່ງ TypeScript).

ເພື່ອຫຼຸດເວລາທີ່ໃຊ້ໃນການ interpret code. ໃນຂະນະທີ່ run byte code, machine code ທີ່ຖືກ optimized ແລ້ວຈະ handle ສະເພາະ case ທີ່ engine ເຄີຍເຫັນມາກ່ອນເທົ່ານັ້ນ. ຖ້າເຮົາໃຊ້ code ບາງສ່ວນທີ່ມັນການ return data type ດຽວກັນຊ້ຳໆ, machine code ທີ່ຖືກ optimized ແລ້ວມັນສາມາດນຳມາໃຊ້ໃໝ່ເພື່ອເພີ່ມຄວາມໄວໄດດ້ຕື່ມອີກ. ແຕ່ເຖິງຢ່າງໃດກໍ່ຕາມ, ເນື່ອງຈາກ JavaScript ຖືກອອກແບບມາໃຫ້ເປັນ dynamic type ມັນອາດຈະມີບາງເຫດການທີ່ວ່າ code ບາງສ່ວນທີ່ຄືກັນແຕ່ມັນ return ຄົນລະ data type ອອກມາ. ຖ້າເກີດເຫດການແບບນີ້ຂຶ້ນ machine code ຈະທຳການ de-optimized ແລະ engine ຈະທຳການກັບໄປ interpreting ເພື່ອ generate byte code ໃໝ່.

ສົມມຸດວ່າເຮົາໄດ້ເອີ້ນໃຊ້ບາງ function ເປັນຈຳນວນ 100 ຄັ້ງ ແລະ ມັນຈະ return ຄ່າເດີມມາສະເໝີ, ມັນຈະຖືວ່າມັນຈະທຳການ return ຄ່າເດີມມາຖ້າຫາກເຮົາເອີ້ນໃຊ້ຮອບທີ 101.

ຖ້າຍັງງົງມາເບິ່ງອີກຕົວຢ່າງ: ສົມມຸດວ່າເຮົາມີ sum function ດັ່ງຕໍ່ໄປນີ້, ເຊິ່ງມັນຈະຖືກເອີ້ນໃຊ້ດ້ວຍການປ້ອນ arguments ທີ່ເປັນຄ່າຕົວເລກທຸກຄັ້ງ:

ໃນ function ດ້ານເທິງມັນຈະ return ຄ່າທີ່ເປັນຕົວເລກອອກມາຄື 3, ຄັ້ງຕໍ່ໄປທີ່ເຮົາເອີ້ນໃຊ້ມັນຈະຖືວ່າເຮົາກຳລັງເອີ້ນໃຊ້ອີກຄັ້ງດ້ວຍ arguments ທີ່ເປັນຕົວເລກ 2 ຄ່າ.

ຖ້າມັນເປັນແບບນັ້ນກໍ່ບໍ່ຈຳເປັນຕ້ອງຄົ້ນຫາແບບ dynamic ແລະ ສາມາດ re-use machine code ທີ່ຖືກ optimized ໄດ້ເລີຍ. ແຕ່ຖ້າບໍ່ເປັນແບບນັ້ນ ມັນກໍ່ຈະ revert ໄປເປັນ original byte code ຂອງ machine code ທີ່ຖືກ optimized.

ຕົວຢ່າງ: ຄັ້ງຕໍ່ໄປທີ່ເຮົາເອີ້ນໃຊ້ເຮົາຈະສົ່ງຄ່າທີ່ເປັນ string ແທນຕົວເລກ, ເນື່ອງຈາກ JavaScript ເປັນ dynamic type ເຮົາຈຶ່ງສາມາດເຮັດແບບນີ້ໄດ້ໂດຍທີ່ບໍ່ມີ Error ໃດໆ.

ໝາຍຄວາມວ່າເລກ 2 ຈະຖືກບີບໃຫ້ເປັນ string ແລະ function ຈະ return ຄ່າ "12" ອອກມາແທນ. ທີ່ເປັນແບບນີ້ກໍ່ຍ້ອນມັນກັບໄປ execute byte code ທີ່ຖືກ interpreted ແລ້ວ ແລະ ທຳການ update type ກັບໄປ.

ອ້າງອີງ: 🚀⚙️ JavaScript Visualized: the JavaScript Engine

JavaScript EP3: Scope (Chain)⛓️🚧

phatsss — Mon, 03 Apr 2023 13:20:47 +0000

ມາຮອດ ep ນີ້, ເຊື່ອວ່າຫຼາຍໆຄົນກໍ່ອາດຈະເຄີຍຂຽນ JS ບໍ່ຫຼາຍກໍ່ໜ້ອຍ, ແຕ່ຈະພະຍາຍາມຍົກຕົວຢ່າງທີ່ງ່າຍ ແລະ ເຂົ້າໃຈໄດ້ພາຍໃນ 3 ວິນາທີ🥹🥹🥹.

ເຮົາມາເບິ່ງ code ກັນກ່ອນເລີຍ:

const name = "Lydia"
const age = 21
const city = "San Francisco"

function getPersonInfo() {
  const name = "Sarah"
  const age = 22

  return `${name} is ${age} and lives in ${city}`
}

console.log(getPersonInfo())

ຈາກ code ຈະເຫັນວ່າເຮົາໄດ້ທຳການ invoke getPersonInfo function ທີ່ມີການ return ຄ່າເປັນ string ອອກມາ, ໃນນັ້ນປະກອບດ້ວຍຕົວປ່ຽນ name, age ແລະ city. ຜົນທີ່ໄດ້ຈາກ code ດ້ານເທິງແມ່ນ Sarah is 22 and lives in San Francisco, ແຕ່ໃນ getPersonInfo function ບໍ່ໄດ້ບັນຈຸຕົວປ່ຽນ city ແລ້ວມັນຮູ້ຈັກຕົວປ່ຽນ city ໄດ້ແນວໃດ?🤔.

ທຳອິດຈະມີການຈັດການພື້ນທີ່ memory ໃນຫຼາຍໆ context ທີ່ແຕກຕ່າງກັນ, ເຮົາມີ global context ເປັນ default(window ໃນ browser ແລະ global ໃນ Node) ແລະ local context ສຳລັບ getPersonInfo function ທີ່ຖືກ invoke. ແຕ່ລະ context ກໍ່ຈະມີ scope chain ເຊັ່ນກັນ.

ສຳລັບ getPersonInfo function, scope chain ຈະມີຂະບວນການປະມານນີ້:

ໂດຍພື້ນຖານແລ້ວ scope chain ເປັນ "chain of references" ໄປຫາ object ທີ່ມີການອ້າງອີງເຖິງ values(ແລະ scopes ອື່ນໆ)ທີ່ຖືກອ້າງອີງຢູ່ໃນ execution context. scope chain ຖືກສ້າງຂຶ້ນຕອນທີ່ execution context ຖືກສ້າງຂຶ້ນ, ໝາຍຄວາມວ່າມັນຖືກສ້າງຕອນ runtime.

ເຖິງຢ່າງໃດກໍ່ຕາມ, ເຮົາຈະຍັງບໍ່ເວົ້າເຖິງ activation object ຫຼື execution contexts ໃນບົດຄວາມນີ້ເທື່ອ(ໃນບົດຄວາມນີ້ເຮົາມາໂຟກັສທີ່ scope ກັນກ່ອນ). ດັ່ງຕົວຢ່າງດ້ານລຸ່ມ key/value ທີ່ຢູ່ນຳ execution contexts ຈະສະແດງເຖິງການອ້າງອີງທີ່ scope chain ມີຕໍ່ຕົວປ່ຽນ.

scope chain ຂອງ global execution context ມີການອ້າງອີງເຖິງ 3 ຕົວປ່ຽນຄື: name ໂດຍມີຄ່າ Lydia, age ມີຄ່າ 21 ແລະ city ມີຄ່າ San Francisco. ໃນ local context ເຮົາມີການອ້າງອີງເຖິງ 2 ຕົວປ່ຽນຄື: name ມີຄ່າ Sarah ແລະ age ມີຄ່າ 22.
ເມື່ອເຮົາ access ເຂົ້າເຖິງຕົວປ່ຽນທີ່ຢູ່ໃນ getPersonInfo, JS Engine ຈະທຳການກວດຢູ່ local scope chain ກ່ອນ.

local scope chain ມີການອ້າງອີງເຖິງ name ແລະ age, name ມີຄ່າ Sarah ແລະ age ມີຄ່າ 22. ເຮົາມາລອງສັງເກດເບິ່ງວ່າຖ້າເຮົາ access ຕົວປ່ຽນ city ຈະເປັນຈັ່ງໃດ?🫣
ເພື່ອຫາ value ຂອງຕົວປ່ຽນ city, JS Engine ຈະທຳການລົງໄປຄົ້ນຫາຕາມ scope chain ໝາຍຄວາມວ່າຖ້າມັນບໍ່ພົບ value ໃນ local scope chain ມັນກໍ່ຈະທຳການຫາຢູ່ໃນ outer scope(scope ທີ່ນອກ local scope)ທີ່ local scope ໄດ້ມີການອ້າງອີງເຖິງ ໃນຕົວຢ່າງດ້ານລຸ່ມຈະແມ່ນ global object.

ໃນ global context ເຮົາໄດ້ປະກາດຕົວປ່ຽນ city ມີຄ່າ San Francisco, ດັ່ງນັ້ນ ຈຶ່ງມີການອ້າງອີງເຖິງຕົວປ່ຽນ city. ຕອນນີ້ເຮົາມີ value ຂອງແຕ່ລະຕົວປ່ຽນແລ້ວຈຶ່ງເຮັດໃຫ້ getPersonInfo function ສາມາດ return ຄ່າທີ່ເປັນ string ອອກມາໄດ້ ແລະ ຜົນທີ່ໄດ້ແມ່ນ Sarah is 22 and lives in San Francisco.

ເຮົາສາມາດລົງໄປຊັ້ນລຸ່ມຂອງ scope chain ໄດ້, ແຕ່ບໍ່ສາມາດຂຶ້ນມາຊັ້ນເທິງຂອງ scope chain ໄດ້ ຫຼື ຈະເອີ້ນວ່າອອກນອກ scope ໄດ້ແຕ່ບໍ່ສາມາດເຂົ້າໄປໃນ scope ແບບນີ້ກໍ່ໄດ້ເຊັ່ນກັນ. ຖ້າຍັງງົງກໍ່ໄປເບິ່ງຕົວຢ່າງນຳກັນເລີຍ😵‍💫.
ໃນຕົວຢ່າງຈະອະທິບາຍໃນລັກສະນະຂອງຂະບວນການໄຫຼຂອງນ້ຳຕົກ(ໄຫຼຈາກເທິງລົງລຸ່ມ).

ຫຼື ກໍລະນີທີ່ມີ function ຊ້ອນກັນອີກກໍ່ຈະມີໜ້າຕາ ແລະ ຊົງຜົມປະມານນີ້:

ເຮົາລອງມາສຶກສາເບິ່ງ code ຕົວຢ່າງນີ້ໄປນຳກັນ

ມັນຄ້າຍຄືກັນກັບຕົວຢ່າງຕັ້ງແຕ່ທຳອິດແທບຈະທຸກຢ່າງ, ແຕ່ເຖິງຢ່າງໃດກໍຕາມມັນມີຈຸດແຕກຕ່າງໃຫຍ່ໆເລີຍກໍ່ຈະແມ່ນ: ເຮົາໄດ້ປະກາດຕົວປ່ຽນ city ຢູ່ໃນ getPersonInfo function ແລະ ບໍ່ຢູ່ໃນ global scope. ໃນທີ່ນີ້ເຮົາບໍ່ໄດ້ invoke getPersonInfo function, ດັ່ງນັ້ນ ມັນຈະບໍ່ມີການສ້າງ local context ເຊັ່ນກັນ. ເຮົາລອງ access ເຖິງ value ຂອງ name, age ແລະ city ໃນ global context ດັ່ງນີ້:

ຜົນທີ່ໄດ້ຄືມັນຈະທຳການໂຍນ ReferenceError ສູດດັ້ງເດີມເຈົ້າເກົ່າມາໃສ່ໜ້າເຮົາ, ສາເຫດກໍ່ຍ້ອນມັນບໍ່ເຫັນຕົວປ່ຽນ city ໃນ global scope, ອີກຢ່າງກໍ່ຄືເຮົາເອີນຈາກ global scope ຢູ່ແລ້ວມັນເລີຍບໍ່ມີ scope ຊັ້ນລຸ່ມໃຫ້ຫາອີກ ແລະ ມັນບໍ່ສາມາດຂຶ້ນໄປຊັ້ນເທິງຂອງ scope ໄດ້ນັ້ນເອງ.
ດ້ວຍວິທີນີ້ເຮົາສາມາດ protect ຕົວປ່ຽນຂອງເຮົາ ແລະ ສາມາດ re-use ຊື່ຕົວປ່ຽນຄືນໄດ້ອີກ.

ນອກຈາກ global scope ແລະ local scope ແລ້ວມັນຍັງມີ block scope ອີກ🤯. ຕົວປ່ຽນທີ່ປະກາດດ້ວຍ let ແລະ const keyword ຈະເປັນຕົວປ່ຽນທີ່ມີ scope ຢູ່ໃນ brackets ({}).

const age = 21

function checkAge() {
  if (age < 21) {
    const message = "You cannot drink!"
    return message
  } else {
    const message = "You can drink!"
    return message
  }
}

ຖ້າເຮົາລອງ visualize scope ອອກມາກໍ່ຈະໄດ້:

ເຮົາມີ global scope, function scope ແລະ block scopes 2 ອັນ. ເຊິ່ງເຮົາສາມາດປະກາດຕົວປ່ຽນ message ໄດ້ 2 ຄັ້ງ, ເນື່ອງຈາກຕົວປ່ຽນຖືກກຳນົດ scope ໄວ້ໃນຂອບເຂດຂອງ brackets.

ສະຫຼຸບ:

ເຮົາຈະເຫັນວ່າ scope chain ເປັນ chain ຂອງການອ້າງອີງເຖິງ value ທີ່ເຮົາສາມາດ access ໄດ້ໃນ context ທີ່ເຮົາກຳລັງເຮັດຢູ່.
scope ເຮັດໃຫ້ເຮົາສາມາດ re-use ຊື່ຂອງຕົວປ່ຽນທີ່ໄດ້ຖືກປະກາດໄວ້ຢູ່ໃນ scope chain, ເນື່ອງຈາກມັນສາມາດເຮັດວຽກແບບລົງຊັ້ນລຸ່ມໄດ້ຢ່າງດດຽວ ແລະ ບໍ່ສາມາດຂຶ້ນໄປຊັ້ນເທິງຂອງ scope ໄດ້.

ອ້າງອີງ:
⚡️⛓JavaScript Visualized: Scope (Chain)

JavaScript EP2: Hoisting🫵🏻

phatsss — Sat, 01 Apr 2023 10:55:07 +0000

Hoisting - JS Developer ຫຼາຍຄົນກໍ່ຄົງຄຸ້ນຫູກັບຄຳນີ້ຢູ່ບໍ່ໜ້ອຍເນື່ອງຈາກຫຼາຍໆເທື່ອທີ່ໄປຄົ້ນວິທີແກ້ error ຢູ່ google ມັກຈະເຫັນຄົນມາບອກວ່າ error ນີ້ເກີດຈາກ hoisting, ແຕ່ hoisting ມັນແມ່ນແບ້ຫຍັງລ່ະ? ດຽວບົດຄວາມນີ້ຈະມາອະທິບາຍວ່າແບ້ອີ່ຫຍັງຄື hoisting.

ຕອນທີ່ເລີ່ມຂຽນ JavaScript ຊ່ວງແລກໆກໍ່ເຄີຍພໍ້ເຫດການທີ່ວ່າ variable ບາງໂຕມັນ undefined ແບບງົງໆ, ຖືກໂຍນ ReferenceErrors ໃສ່ໜ້າ ແລະ ອີກບັນຫາອື່ນໆ. Hoisting ມັກຖືກຫຼາຍຄົນອະທິບາຍວ່າເປັນການໃສ່ຕົວປ່ຽນ ແລະ function ໄວ້ຢູ່ເທິງສຸດຂອງໄຟລ໌, ແຕ່ວ່າ ມັນແມ່ນແບບນັ້ນແທ້ບໍ່ລ່ະ? ໃຈເຢັນກ່ອນໄບຣ໌ອັນມັນບໍ່ແມ່ນແບບນັ້ນເລີຍ, ມັນບໍ່ແມ່ນສາເຫດຂອງສິ່ງທີ່ເກີດຂຶ້ນ ເຖິງມັນຊິເບິ່ງຄືວ່າມັນໜ້າຈະເປັນແບບນັ້ນກໍ່ຕາມ.

ເມື່ອ JavaScript Engine ເລີ່ມເຮັດວຽກກັບ script ທີ່ເຮົາຂຽນ ສິ່ງທຳອິດທີ່ມັນເຮັດກໍ່ຄືການຕັ້ງຄ່າ memory ສຳລັບ data ໃນ code ຂອງເຮົາ. ຈະຍັງບໍ່ມີການ execute ໃດໆໃນຂັ້ນຕອນນີ້ເທື່ອ ເວົ້າງ່າຍໆກໍ່ຄືມັນເປັນພຽງການກະກຽມທຸກຢ່າງສຳລັບການ execution. ວິທີການໃນການ store ສ່ວນຂອງ function ແລະ ຕົວປ່ຽນນັ້ນແຕກຕ່າງກັນ, function ຈະຖືກ store ໄວ້ໂດຍອ້າງອີງ function ທັງໝົດ.

ສ່ວນຂອງຕົວປ່ຽນຈະມີຈຸດທີ່ແຕກຕ່າງຢູ່ໜ້ອຍໜຶ່ງຄື: ໃນ ES6+ ຈະມີການປະກາດຕົວປ່ຽນແບບ let ແລະ const. ຕົວປ່ຽນທີ່ປະກາດດ້ວຍ let ແລະ const keyword ຈະຖືກ store ແບບ uninitialized

ຕົວປ່ຽນທີ່ປະກາດດ້ວຍ var keyword ຈະຖືກ store ດ້ວຍຄ່າ default ຄື undefined

ເມື່ອຂັ້ນຕອນຕ່າງໆທີ່ກ່າວມາສຳເລັດແລ້ວ ເຮົາຈຶ່ງຈະສາມາດ execute code ໄດ້. ມາເບິ່ງນຳກັນວ່າຖ້າເຮົາໃຊ້ console.log() 3 ອັນຢູ່ເທິງສຸດຂອງໄຟລ໌ກ່ອນທີ່ເຮົາຈະປະກາດຟັງຊັ່ນ ແລະ ຕົວປ່ຽນ. ເວົ້າງ່າຍກໍ່ຄືເອີ້ນໃຊ້ກ່ອນທີ່ຈະປະກາດ
ເນື່ອງຈາກ function ຖືກ store ໄວ້ໂດຍການອ້າງອີງເຖິງ code ທັງໝົດ, ດັ່ງນັ້ນເຮົາຈະເຫັນວ່າເຮົາສາມາດເອີ້ນໃຊ້ function ກ່ອນທີ່ເຮົາຈະປະກາດ function.

ເມື່ອເຮົາອ້າງເຖິງຕົວປ່ຽນທີ່ປະກາດດ້ວຍ var keyword ແລ້ວທຳການເອີ້ນໃຊ້ກ່ອນທີ່ຈະປະກາດຕົວປ່ຽນ, ແນ່ນອນວ່າມັນຈະໂຍນຄ່າ default ມາໃຫ້ນັ້ນກໍ່ຄື: undefined, ແຕ່ບາງເທື່ອມັນກໍ່ຈະເປັນ unexpected. ໃນຫຼາຍໆກໍລະນີຖ້າພົບເຫດການແບບນີ້ແມ່ນໃຫ້ສັນນິຖານໄວ້ກ່ອນເລີຍວ່າ: ເຮົາອາດຈະລືມປະກາດຕົວປ່ຽນກ່ອນການເອີ້ນໃຊ້ຫຼືບໍ່?

ເພື່ອປ້ອງກັນບໍ່ໃຫ້ສາມາດອ້າງອີງຕົວປ່ຽນທີ່ເປັນ undefined ເຊັ່ນດຽວກັບການເອີ້ນໃຊ້ var keyword ທີ່ເຮົາເຫັນໃນຕົວຢ່າງ. ຈະມີ ReferenceError ຖືກໂຍນອອກມາເມື່ອໃດກໍ່ຕາມທີ່ເຮົາພະຍາຍາມເອີ້ນໃຊ້ຕົວປ່ຽນທີ່ເປັນ uninitialized. zone ທີ່ເຮົາເອີ້ນໃຊ້ຕົວປ່ຽນກ່ອນການປະກາດຈະເອີ້ນວ່າ: temporal dead zone - ເຮົາບໍ່ສາມາດອ້າງອີງ ຫຼື ເອີ້ນໃຊ້ຕົວປ່ຽນກ່ອນການ initialization ໄດ້(ລວມໄປເຖິງ classes ນຳ)

ເມື່ອ JavaScript Engine ເຮັດວຽກຮອດແຖວທີ່ເຮົາປະກາດຕົວປ່ຽນໄວ້, ມັນຈະທຳການຂຽນທັບ value ທີ່ຢູ່ໃນ memory ທີ່ເປັນ value ທີ່ເຮົາຂຽນໄວ້ໃນ code.

ສະຫຼຸບ:

function ແລະ variables ຈະຖືກ store ໄວ້ໃນ memory ສຳລັບການ execution ກ່ອນທີ່ຈະທຳການ execute code ຂອງເຮົາ, ຂະບວນການທີ່ວ່າມາເອີ້ນວ່າ hoisting.
function ຈະຖືກ store ໂດຍອ້າງອີງເຖິງ function ທັງໝົດ, ສ່ວນຕົວປ່ຽນທີ່ໃຊ້ var keyword ຈະຖືກ store ດ້ວຍຄ່າ default ຄື: undefined ແລະ ຕົວປ່ຽນທີ່ໃຊ້ let ແລະ const keyword ແມ່ນຈະຖືກ store ດ້ວຍ uninitialized

ອ້າງອີງ: 🔥🕺🏼 JavaScript Visualized: Hoisting

JavaScript EP1: Event Loop♻️

phatsss — Thu, 30 Mar 2023 17:49:30 +0000

ຫ່າງຫາຍໄປດົນສົມຄວນ, ດຽວມື້ນີ້ຈະຂຽນເລື່ອງເບື້ອງເລິກເບື້ອງຫຼັງຂອງພາສາ JavaScript ໃຫ້ອ່ານເພື່ອເປັນພື້ນຖານໃນການນຳໃຊ້ພາສາ JavaScript ໃຫ້ມີປະສິດທິພາບ(ຫຼືບໍ່?).

Hey JS ♻️!

JS ເປັນພາສາທີ່ເຮັດວຽກແບບ single-threaded ແລະ non-blocking ໝາຍຄວາມວ່າມັນຈະເຮັດວຽກພຽງແຕ່ 1 task ຕໍ່ຄັ້ງ, ເບິ່ງຄືວ່າມັນກໍ່ບໍ່ມີບັນຫາຫຍັງ ແຕ່ລອງຄິດພາບເບິ່ງວ່າເຮົາມີ task ທີ່ຕ້ອງ process ໂດຍໃຊ້ເວລາທັງໝົດ 30 ວິນາທີ. ໃນຂະນະທີ່ task ຍັງເຮັດວຽກບໍ່ແລ້ວເທື່ອ, ແຕ່ເຮົາຕ້ອງມານັ່ງຖ້າ 30 ວິນາທີກ່ອນທີ່ຈະເກີດເຫດການອື່ນໆຕໍ່(JS ຈະ run ຢູ່ເທິງ main thread ຂອງ browser by default ຢູ່ແລ້ວ, ດັ່ງນັ້ນ UI ທຸກຢ່າງຈະຍັງຄ້າງຢູ່ແບບນັ້ນ)😖 ແລ້ວໃຜຊິມານັ່ງຖ້າເວັບຊ້າໆແບບນັ້ນລ່ະ? ນີ້ມັນ 2023 ແລ້ວໃດ🤣🤣🤣

ໂຊກດີແນ່ທີ່ browser ມີບາງ features ທີ່ JavaScript engine ບໍ່ມີມາໃຫ້ເຊັ່ນ: Web API - ໃນນີ້ປະກອບມີ DOM API, setTimeout, HTTP requests ເປັນຕົ້ນ, ເຊິ່ງມັນເຮັດໃຫ້ເຮົາສາມາດຂຽນແບບ async, non-blocking ໄດ້.

ເມື່ອເຮົາເອີ້ນໃຊ້ function ໃດໆກໍ່ຕາມ, ສິ່ງທຳອິດທີ່ມັນເຮັດກໍ່ຄືມັນຈະ added ເຂົ້າໄປໃນ call stack. call stack ເປັນສ່ວນໜຶ່ງຂອງ JS engine ແລະ ມັນບໍ່ໄດ້ເປັນສິ່ງທີ່ມີສະເພາະ browser - ໝາຍຄວາມວ່າມັນເປັນ stack ລັກສະນະການເຮັດວຽກຂອງມັນກໍ່ຈະເປັນແບບ first in, last out (ຄິດພາບຈານໃສ່ເຂົ້າທີ່ກອງກັນເປັນຊັ້ນໆ ເມື່ອເຮົາຈະໃຊ້ຈານເຫຼົ່ານັ້ນແມ່ນເຮົາຈະທຳການຢິບເອົາຈາກອັນທີ່ຢູ່ເທິງສຸດກ່ອນ)🥞 ແລະ ເມື່ອ function ທີ່ເຮົາເອີ້ນໃຊ້ທຳການ return value ຫຼື ເຮັດວຽກສຳເລັດແລ້ວ ມັນຈະຖືກ popped ອອກໄປຈາກ stack.

function ທີ່ຖືກເອີ້ນໃຊ້ຈະຖືກ pushed ເຂົ້າໄປໃນ call stack.
ເຮັດວຽກບາງຢ່າງພາຍໃນ function ແລ້ວ return value.
ຫຼັງຈາກເຮັດວຽກສຳເລັດ function ນັ້ນຈະຖືກ popped ອອກໄປຈາກ stack.

ຈາກຕົວຢ່າງເຫັນວ່າ respond function ມີການ return setTimeout function. ເຊິ່ງ setTimeout ແມ່ນໄດ້ມາຈາກ Web API - ໃຊ້ໃນການ delay task ໂດຍທີ່ບໍ່ມີການ block main thread. callback function ທີ່ເຮົາ passed ໄປຍັງ setTimeout function, ຈະຢູ່ໃນຮູບແບບ arrow function () => { return 'Hey'} ຈະຖືກ added ໄປຍັງ Web API. ໃນຂະນະດຽວກັນ setTimeout function ແລະ respond function ຈະຖືກ popped ອອກຈາກ stack ແລະ ທັງ 2 function ຈະ return value ຂອງຕົວເອງ.

ໃນສ່ວນຂອງ Web API ຈະມີຕົວຈັບເວລາ(timer)ຈະຣັນໄປເລື້ອຍໆຈົນກວ່າຈະຄົບ 1000ms ແລ້ວຈຶ່ງຈະເຮັດສ່ວນຂອງ argument ທີ 2 ທີ່ເຮົາ passed ເຂົ້າໄປ. callback function ຈະຍັງບໍ່ຖືກ added ເຂົ້າໄປໃນ call stack ເທື່ອ, ແຕ່ຈະ passed ເຂົ້າໄປໃນ queue ແທນ.

ໃນສ່ວນນີ້ອາດຈະສັບສົນໜ້ອຍໜຶ່ງ, ຈາກຕົວຢ່າງໝາຍຄວາມວ່າ: ຫຼັງຈາກທີ່ timer ເຮັດວຽກໄປຈົນຄົບ 1000ms callback function ຂອງເຮົາຈະຖືກ added ເຂົ້າໄປໃນ queue ກ່ອນເພື່ອລໍຖ້າໃນການທີ່ຈະຖືກ added ເຂົ້າໄປໃນ call stack ອີກເທື່ອໜຶ່ງ 😵‍💫.

ແລະພະເອກຂອງເຮົາໃນ ep ນີ້ກໍ່ຄື: event loop ນີ້ເອງງງງ😎 - ອັນທີ່ຈິງ event loop ມີໜ້າທີພຽງແຕ່ connecting queue ກັບ call stack ຖ້າ call stack ວ່າງຢູ່(empty)ເທົ່ານັ້ນ🤣🤣🤣. ດັ່ງນັ້ນ ຖ້າຫາກທຸກໆ function ທີ່ຖືກເອີ້ນໃຊ້(invoked)ໄດ້ return value ຂອງຕົວເອງ ແລະ ຖືກ popped ອອກຈາກ call stack ແລ້ວ, item ທຳອິດທີ່ຢູ່ໃນ queue ຈະຖືກ added ເຂົ້າມາໃນ call stack. ໃນກໍລະນີນີ້ບໍ່ມີ function ອື່ນທີ່ຖືກເອີ້ນໃຊ້, ດັ່ງນັ້ນມັນຈຶ່ງຢິບເອົາ item ທຳອິດທີ່ຢູ່ໃນ queue(ໃນນີ້ມີພຽງ 1 item)ແລ້ວ added ເຂົ້າໃນ call stack.

ຂະບວນການໂດຍຫຍໍ້: callback ໄດ້ຖືກ added ເຂົ້າໄປໃນ call stack, ເອີ້ນໃຊ້(invoked0, return value, popped callback ອອກຈາກ call stack.

ຫຼັງຈາກທີ່ອ່ານຂະບວນການການເຮັດວຽກຂອງ JS ດ້ານເທິງແລ້ວ ເຮົາມາລອງເຝິກສະໝອງດ້ວຍການລອງຄິດພາບການເຮັດວຽກຂອງຂະບວນການດ້ານລຸ່ມເບິ່ງວ່າ function ໃດຈະເຮັດວຽກສຳເລັດກ່ອນກັນ.

const foo = () => console.log("First");
const bar = () => setTimeout(() => console.log("Second"), 500);
const baz = () => console.log("Third");

bar();
foo();
baz();

ຈາກ code ດ້ານເທິງຈະມີຂະບວນການດັ່ງນີ້:

ອະທິບາຍ:

ເຮົາເອີ້ນໃຊ້(invoked) bar function, bar ຈະ return setTimeout function.
callback ທີ່ເຮົາ passed ເຂົ້າໄປໃນ setTimeout ຈະຖືກ added ເຂົ້າໄປໃນ Web API, ເຊິ່ງ setTimeout function ແລະ bar ຈະຖືກ popped ອອກຈາກ call stack.
timer ຈະຣັນໄປເລື້ອຍໆ, ໃນຂະນະດຽວກັນ foo function ກໍ່ຖືກເອີ້ນໃຊ້ ແລະ logs ຄ່າອອກມາ First. foo return (undefined), baz ຖືກເອີ້ນໃຊ້ ແລະ callback ກໍ່ຖືກ added ເຂົ້າໄປໃນ queue.
baz ຈະ logs ຄ່າ Third. event loop ເຫັນວ່າ call stack ວ່າງຢູ່(empty) ຫຼັງຈາກທີ່ baz ໄດ້ທຳການ return ຄ່າສຳເລັດ. ຫຼັງຈາກທີ່ແຕ່ລະ callback ຖືກ added ເຂົ້າໄປໃນ call stack ແລ້ວ.
callback ຈະ logs ຄ່າ Second

ບ່ອນອ້າງອີງ:

✨♻️ JavaScript Visualized: Event Loop

ສິ່ງທີ່ຄວນຮູ້ກ່ອນທີ່ຈະເປັນ web 3 developer

phatsss — Wed, 15 Mar 2023 08:46:15 +0000

ເຊື່ອວ່າຄົນທີ່ເຂົ້າມາອ່ານບົດຄວາມນີ້ຕ້ອງເຄີຍໄດ້ຍິນຄຳວ່າ web 3.0 ມາແລ້ວທຸກຄົນ, ແຕ່ເຄີຍສົງໄສບໍ່ວ່າ web 3.0 ໃນເນື້ອຫາສາລະ ແລະ ຄຸນສົມບັດຂອງມັນຄອບຄຸມຮອດໄສແນ່?, ຄວາມສາມາດຂອງ web 3.0 ຕ່າງຈາກ web 2.0 ຫຼື web 1.0 ແນວໃດ?, ວິທີການພັດທະນາ web 3.0 ເຮັດແນວໃດ? ຫຼື ລວມໄປເຖິງການທີ່ຈະກ້າວໄປເປັນ web 3 developer ຕ້ອງຮູ້ຫຍັງ ແລະ ຮຽນຫຍັງແນ່?. ເຊິ່ງໃນບົດຄວາມຊຸດນີ້ເຮົາຈະຄ່ອຍໆແກະລາຍລະອຽດຂອງ web3 ອອກມາເບິ່ງນຳກັນ, ຖ້າພ້ອມແລ້ວໄປກັນເລີຍ🧑🏻‍💻🧑🏻‍💻🧑🏻‍💻

web 3.0 ແມ່ນຫຍັງ? - ແນວຄິດພື້ນຖານ

ໂດຍພຶ້ນຖານແລ້ວ, web 3.0 ຖືວ່າເປັນ big deal ສຳລັບທຸກໆຄົນເລີຍແຫຼະ ເນື່ອງຈາກວ່າມັນມີສັກກະຍະພາບພຽງພໍໃນການປ່ຽນແປງໂລກທັງໃບເລີຍກໍ່ວ່າໄດ້(ໂມ້ບໍ່ວ່ະ 5555). ຖ້າເຮົາສັງເກດເບິ່ງເທຣນຊ່ວງຫຼັງໆນີ້ຮູ້ສຶກວ່າມີຂ່າວກ່ຽວກັບເລື່ອງຂອງ web3(web 3.0) ຢູ່ຫຼາຍສົມຄວນ, ຫຼາຍໆແຫຼ່ງຂ່າວກໍ່ບອກວ່າມັນເປັນແນວຄິດແຫ່ງອານາຄົດພຸ້ນລ່ະ(ມັນຄືເປັນຕາສຶກສາແທ້ລ່ະ) ຖ້າເຮົາເລີ່ມສຶກສາຕັ້ງແຕ່ມື້ນີ້ຖາມວ່າຕົກເທຣນບໍ່? ຖ້າເຮົາເບິ່ງຕາມເທຣນຂອງທົ່ວໂລກບອກໄດ້ເລີຍວ່າກຳລັງເໝາະ(ແຕ່ໜ້າວຽກຢູ່ບ້ານເຮົາກໍ່ຕ້ອງເບິ່ງຕົວຈິງອີກຕື່ມ - ສຶກສາໄວ້ກໍ່ບໍ່ເສຍຫາຍ). ຫຼາຍຄົນກໍ່ສຶກສາໄປຈົນຮອດສາມາດສ້າງ blockchain project ເປັນຂອງຕົວເອງແລ້ວສາມາດປ່ຽນຕຳແໜ່ງວຽກ ແລະ ເພີ່ມຜົນຕອບແທນຂອງຕົວເອງໄດ້ຫຼາຍເລີຍ(ແຕ່ບໍ່ແມ່ນຜູ້ຂຽນເດີ ຮະຮະຮ່າາາ).

ໃນ web 2.0 ຂໍ້ມູນທຸກຢ່າງແມ່ນຖືກຈັດເກັບຢູ່ສູນກາງ ແລະ ຂໍ້ມູນເຫຼົ່ານັ້ນກໍ່ຖືກຄວບຄຸມໂດຍບັນດາບໍລິສັດ big tech ທັງຫຼາຍທີ່ໃຫ້ບໍລິການໃນການແລກປ່ຽນຂໍ້ມູນສ່ວນບຸກຄົນ(ຂໍ້ມູນຂອງຜູ້ໃຊ້). ສ່ວນຢູ່ໃນ decentralized web(web ທີ່ໄຮ້ສູນກາງ)ຈະບໍ່ຂຶ້ນກັບບຸກຄົນໃດໜຶ່ງ, ບໍລິສັດ/ອົງກອນຕ່າງໆສາມາດແປຮູບ data ຫຼື information ກ່ຽວກັບໃຜ ຫຼື ສິ່ງໃດໆກໍ່ໄດ້ ແລະ ຂໍ້ມູນທຸກຢ່າງຈະເປັນ public ໝາຍຄວາມວ່າຈະບໍ່ມີບຸກຄົນໃດໜຶ່ງມີສິດຄວບຄຸມຂໍ້ມູນທັງໝົດ ທຸກຄົນສາມາດນຳໃຊ້ຂໍ້ມູນຕ່າງໆທີ່ຢູ່ເທິງໄດ້. web3 ກໍ່ສາມາດເວົ້າໄດ້ວ່າມັນເປັນ decentralized web ໄດ້ເຊັ່ນກັນ, ມັນເປັນເຟດ(phase)ທີ 3 ຂອງ internet ແລະ ມັນຖືກສ້າງຂຶ້ນມາບົນພື້ນຖານຂອງ peer-to-peer network ຂອງເຄືອຂ່າຍຄອມພິວເຕີທີ່ແຕ່ລະເຄື່ອງຈະບໍ່ມີເຄື່ອງໃດທີ່ເປັນຕົວກາງ.

ໃນນິຍາມຂອງ web3 ແມ່ນມັນຈະມີອີກຫຼາຍຄຸນສົມບັດ, ແຕ່ສະຫຼຸບໃຫ້ສັ້ນທີ່ສຸດເພື່ອໃຫ້ເຂົ້າໃຈງ່າຍຂຶ້ນ.

ຢາກເປັນ web3 developer ຕ້ອງມີສະກິວຫຍັງແດ່?

ການທີ່ເຮົາຈະອັບສະກິວໂຕເອງໄປເປັນ web3 developer ເຕັມຕົວມັນກໍ່ອາດຈະໃຊ້ເວລາພໍສົມຄວນ, ແຕ່ຖ້າເຮົາມີການວາງແຜນຢ່າງຈິງຈັງໃນການສຶກສາ ຜູ້ຂຽນເຊື່ອວ່າທຸກຄົນສາມາດເປັນ web3 developer ໄດ້. ເຮົາມາເບິ່ງກັນວ່າບັນດາ skills ຕ່າງໆທີ່ເຮົາຄວນສຶກສາມີຫຍັງແດ່? ອ່ານຕໍ່ດ້ານລຸ່ມໄດ້ເລີຍ.

Web 2.0 skills

ຢ່າຟ້າວຫ້າວໃສ່ web3 ຖ້າການເປັນ web2 developer ຍັງບໍ່ແຂງແຮງເທື່ອ, ເລື່ອງນີ້ມັນບໍ່ຕະລົກເລີຍຖ້າຫາກຄວາມຮູ້ພື້ນຖານດ້ານ web2 ຂອງເຮົາຍັງບໍ່ແໜ້ນພໍ ແລ້ວເຮົາພັດຢາກຈະຂ້າມຂັ້ນໄປເລີ່ມສຶກສາພວກ web3 stack ເລີຍ ການເຮັດແບບນີ້ຂ້ອນຂ້າງມີຄວາມສ່ຽງຫຼາຍດ້ານ, ເຊິ່ງມັນອາດຈະສົ່ງຜົນຕໍ່ການພັດທະນາຂອງເຮົາ ແລະ ລວມໄປເຖິງບັນດາ code ທີ່ເຮົາຂຽນອີກ. ສະນັ້ນ ການທີ່ຈະກ້າວໄປຫາ web3 ຄວນເຂົ້າໃຈຂະບວນການພັດທະນາ web2 ໃຫ້ເລິກພໍສົມຄວນ - ຖ້າຖາມວ່າໄປສຶກສາ web3 ເລີຍຜິດບໍ່? ຫຼື ລົງມີຂຽນ smart contact ເຮັດ blockchain project ຜິດບໍ່? ຄຳຕອບມັນກໍ່ບໍ່ຜິດດອກຖ້າຫາກເຮັດອອກມາແລ້ວມັນດີ ແລະ ຄຳວ່າດີໃນທີ່ນີ້ຄືຕ້ອງວັດຜົນໄດ້ໃນດ້ານຕ່າງໆອີກເຊັ່ນ: ຄວາມປອດໄພ, ປະສົບການການໃຊ້ງານຂອງ users, performance ຂອງ app, ແຜນໃນການ scale app ແລະ ຍັງອີກຫຼາຍໆຂໍ້ທີ່ເຮົາຕ້ອງໄດ້ຄຳນຶງເຖິງກ່ອນການພັດທະນາ.

ໂດຍປົກກະຕິ, ເຮົາຈະບໍ່ສາມາດກາຍເປັນ master web3 ໄດ້ເລີຍຖ້າຫາກບໍ່ມີ background ຈາກ web2 ທີ່ດີພໍຕົວ. ດັ່ງນັ້ນ ກ່ອນເຮົາຈະສຶກສາດຳດິ່ງເລິກລົງສູ່ຫຼຸມຂອງ web3 stack ມັນກໍ່ລ້ວນແລ້ວແຕ່ຕ້ອງມີພື້ນຖານທີ່ດີຈາກ web2 ທັງນັ້ນ.

ຖ້າເຮົາມີສະກິວພື້ນຖານໃນການພັດທະນາ web2 ເຊັ່ນ: ReactJS, VueJS, AngularJS ຫຼື ອື່ນໆທີ່ກ່ຽວຂ້ອງມັນກໍ່ຈະເປັນຕົວຊ່ວຍຊັ້ນດີໃນການທີ່ຈະອັບສະກິວໄປເປັນ web3 developer ຍ້ອນວ່າບັນດາ decentralized applications ມີ standard ມາຈາກ Vanilla Javascript ຫຼື Javascript Front-end Frameworks.

Blockchain Fundamentals

ຢາກເປັນ web3 developer ຕ້ອງຮູ້ ແລະ ເຂົ້າໃຈກ່ຽວກັບ Blockchain ຢ່າງຫຼີກລ່ຽງບໍ່ໄດ້, ຖ້າຖາມວ່າຕ້ອງຮູ້ເລິກສ່ຳໃດ? - ກໍ່ຄວນຮູ້ ແລະ ເຂົ້າໃຈໃນລະດັບທີ່ວ່າ: ສາມາດອະທິບາຍໄດ້ວ່າ blockchain ແມ່ນຫຍັງ?, ມັນເຮັດວຽກຈັ່ງໃດ?, ເປັນຫຍັງເຮົາຈຶ່ງໃຊ້ມັນ?.

Blockchain ແມ່ນຫຍັງ?
ໃນທີ່ນີ້ຈະຂໍອະທິບາຍວ່າ blockchain ເປັນ ເຄື່ອຂ່າຍ(network)ຂອງຄອມພິວເຕີທີ່ມີການແບ່ງປັນຂໍ້ມູນ ຫຼື ໃຊ້ຂໍ້ມູນຮ່ວມກັນ ແລະ ເຊື່ອມຕໍ່ກັນໃນລັກສະນະທີ່ການປ່ຽນເປັນຂໍ້ມູນເປັນໄປໄດ້ຍາກ ຫຼື ອາດເວົ້າໄດ້ວ່າມັນແທບຈະເປັນໄປບໍ່ໄດ້ເລີຍທີ່ຈະເຈາະ ຫຼື ໂກງໃນລະບົບ. ມັນເປັນລະບົບທີ່ໄຮ້ສູນກາງ, ມີການກະຈາຍອຳນາດ ແລະ ມີການບັນທຶກທຸກທຸລະກຳທີ່ເກີດຂຶ້ນເອີ້ນວ່າ blocks(ໃຊ້ໃນການບັນທຶກທຸລະກຳທີ່ເກີດຂຶ້ນຢູ່ເທິງເຄືອຂ່າຍຄອມພິວເຕີ).

ອ່ານມາຮອດດບ່ອນນີ້ເຊື່ອວ່າທຸກຄົນຈະເຂົ້າໃຈກ່ຽວກັບ blockchain technology ໃນບໍລິບົດອື່ນໆນອກເໜືອຈາກເລື່ອງຂອງ cryptocurrencies. ມັນຖືກນຳໃຊ້ໃນອີກຫຼາຍໆດ້ານເຊັ່ນ: decentralized finance(De-Fi), NFTs, Gaming, Metaverse, supply chain tracking ແລະ ອື່ນໆ. ນອກຈາກນີ້ເຮົາກໍ່ຕ້ອງຄົ້ນຄວ້າເບິ່ງອີກຕື່ມວ່າ: blockchain ແມ່ນຫຍັງ?(ໂດຍນິຍາມ), ມັນເຮັດວຽກຈັ່ງໃດ?, ເຮົາຈະນຳໃຊ້ ຫຼື ໂຕ້ຕອບກັບ blockchain ໄດ້ແນວໃດ? ແລະ ວິທີການທີ່ຈະ integrated web applications ກັບ blockchain technology ເຮັດແນວໃດ?.

ສຳລັບຜູ້ທີ່ກຳລັງມີໄຟ ແລະ ສົນໃຈກ່ຽວກັບ blockchain ກໍ່ອາດຈະເລີ່ມຈາກສຶກສາ Ethereum blockchain ເພາະວ່າມັນເປັນ network ທີ່ນິຍົມຫຼາຍ, ຄົ້ນຫາຂໍ້ມູນຂ້ອນຂ້າງງ່າຍ ມັນຈຶ່ງເປັນປະໂຫຍດຫຼາຍໃນການຊ່ວຍໃຫ້ເຮົາເລີ່ມຕົ້ນສຶກສາໃນເລື່ອງຂອງ blockchain.

ຖ້າຍັງຄິດພາບບໍ່ອອກໃຫ້ລອງຄິດວ່າ blockchain ປຽບເໝືອນຖານຂໍ້ມູນທີ່ບັນທືກບັນດາຂໍ້ມູນທຸລະກຳທີ່ເກີດຂຶ້ນຢູ່ເທິງ blockchain.

Smart Contracts

smart contracts ເປັນ software(ຊຸດຄຳສັ່ງ)ທີ່ຖືກຈັດເກັບໄວ້ຢູ່ໃນບັນດາ blockchain-based platform, ເຊິ່ງມີຈຸດປະສົງເພື່ອດຳເນີນການ, ຄວບຄຸມ ຫຼື ບັນທຶກເອກະສານຕາມເຫດການ ແລະ actions ທີ່ກ່ຽວຂ້ອງຢ່າງອັດຕະໂນມັດພາຍໃຕ້ເງື່ອນໄຂ ແລະ ຂໍ້ຕົກລົງຕ່າງໆທີ່ກຳນົດໄວ້. ໃນການໃຊ້ smart contracts ເຮົາສາມາດນຳໃຊ້ບັນດາຊຸດຄຳສັ່ງສະເພາະຂອງ blockchain ໃນການດຳເນີນການໄດ້.

ແລະເຊັ່ນດຽວກັບສິ່ງອື່ນໆທີ່ຣັນຢູ່ເທິງ blockchain, ເຮົາບໍ່ສາມາດແກ້ໄຂ ຫຼື ປ່ຽນແປງ code ຂອງ smart contracts ໄດ້ບໍ່ວ່າຈະກໍລະນີໃດໆກໍ່ຕາມ. ອີງຕາມຂໍ້ກຳນົດຂອງຝັ່ງ technical ທີ່ລະບຸວ່າມັນຕ້ອງ immutability(ບໍ່ສາມາດປ່ຽນແປງໄດ້). Smart contracts ສາມາດນຳໃຊ້ເຮັດໄດ້ຫຼາຍຢ່າງແຕ່ທີ່ເຫັນໃຊ້ກັນຢ່າງແພ່ຫຼາຍກໍ່ຈະມີ: ສ້າງ Cryptocurrency, mint NFTs, ໃຊ້ຈັດການ backend ຂອງ decentralized application ເຫຼົ່ານີ້ເປັນຕົ້ນ.

ເມື່ອຮູ້ແລ້ວວ່າ smart contracts ມີຄວາມສຳຄັນສ່ຳໃດໃນ blockchain, ຂັ້ນຕອນຕໍ່ໄປກໍ່ຄົງຈະແມ່ນການທີ່ຕ້ອງຮຽນຮູ້ວິທີພັດທະນາມັນແມ່ນບໍ່ລ່ະ?. ສະນັ້ນ ໃນການຂຽນ smart contracts ໃຫ້ໄປຣັນຢູ່ເທິງ blockchain ເຮົາອາດຈະຕ້ອງມີຄວາມຮູ້ເລື່ອງຂອງພາສາໂປຣແກຣມທີ່ຊື່ວ່າ Solidity, ແນ່ນອນວ່າມັນບໍ່ໄດ້ມີພຽງພາສາດຽວທີ່ສາມາດໃຊ້ພັດທະນາ ແຕ່ Solidity ຖືວ່າເປັນພາສາທີ່ໄດ້ຮັບຄວາມນິຍົມຫຼາຍ ແລະ ມີຂໍ້ມູນທີ່ຂຽນກ່ຽວກັບການຂຽນພາສານີ້ອອກມາຫຼາຍ, ເຊິ່ງມັນເປັນຜົນດີຕໍ່ກັບຜູ້ທີ່ກຳລັງສຶກສາຢູ່.

Solidity ເປັນ object-oriented programming language ທີ່ໃຊ້ສຳລັບການຂຽນ smart contracts, ມັນຖືກໃຊ້ໃນການ implement smart contract ເທິງບັນດາ blockchain platform ຕ່າງໆ ແລະ ມັນຍັງເປັນພາສາໃໝ່ທີ່ໃຊ້ໃນ Ethereum blockchain ທີ່ລວມເອົາຂໍ້ດີຈາກຫຼາຍໆພາສາ, ເຊິ່ງຜູ້ທີ່ສ້າງພາສາ Solidity ໄດ້ຮັບແຮງບັນດານໃຈມາຈາກ JavaScript, Java, C++, Rust ແລະ ອີກຫຼາຍໆພາສາ ຈຶ່ງເຮັດໃຫ້ Solidity ມີຄວາມຫຼາກຫຼາຍ ແລະ ໃຊ້ງານງ່າຍ.

ເມື່ອເຮົາເລີ່ມຂຽນ Solidity ເຮົາຈະສັງເກດເຫັນຄວາມໃກ້ຄຽງກັບພາສາໂປຣແກຣມອື່ນໆ ຕົວຢ່າງດ້ານລຸ່ມ:

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.19;

import "hardhat/console.sol";

contract FirstContract {
    constructor() {
        console.log("Hey, This is Spata!!!");
    }
        function get() public view returns (string memory) {
                return 'I love her, but she got sugar daddy';
        }
}

ອີກຂໍ້ດີຢ່າງໜຶ່ງຂອງການຮຽນພາສາ Solidity ກໍ່ຄືເລື່ອງຂອງຕະຫຼາດແຮງງານດ້ານນີ້(ຕ່າງປະເທດ), ຫຼາຍໆບໍລິສັດທີ່ມີໂປຣເຈັກ Blockchain ຂອງຕົວເອງກໍ່ຕ້ອງການນັກພັດທະນາດ້ານນີ້ຫຼາຍຂຶ້ນ.

ໃນຂະບວນການພັດທະນາ smart contract ຖ້າເຮົາ deploy ໄປແລ້ວແນ່ນອນວ່າມັນບໍ່ສາມາດແກ້ໄຂ code ໄດ້, ດັ່ງນັ້ນການພັດທະນາຕ້ອງໄດ້ມີເຄື່ອງມືຫຼາຍໆຢ່າງທີ່ໃຊ້ໃນແຕ່ລະດ້ານເຊັ່ນ:

ບັນດາ Solidity Frameworks ອາດຈະເລືອກ Hardhat ຫຼື Truffle.
ເຄື່ອງມືໃນການທົດສອບ(Testing)ມີ Mocha, Chai ຫຼື Ganache.
ເຄື່ອງມືໃນການພັດທະນາ(Development)ມີ Infura ຫຼື Alchemy. *ລືມໄປອີກຢ່າງໜຶ່ງ,ມີເວັບແອັບທີ່ຊື່ວ່າ Remix IDE ທີ່ໃຊ້ໃນການພັດທະນາ, ການ Deploy ແລະ ການຈັດການກັບ smart contract ສຳລັບ Ethereum blockchain.

Decentralized Applications (dApps)

ຫຼັງຈາກທີ່ເຮົາຂຽນ ແລະ deploy smart contract ຂອງເຮົາສຳເລັດແລ້ວ, ເຮົາກໍ່ຄວນມີສ່ວນທີ່ໃຫ້ User ເຂົ້າໄປໃຊ້ງານ ແລະ ບ່ອນນີ້ເອງທີ່ເຮົາຈະໄດ້ໃຊ້ສະກິວ web 2.0 ຂອງເຮົາ. ການທີ່ຈະສ້າງ dApp(ເປັນໄດ້ທັງ web ແລະ app) ຂຶ້ນມາໃຫ້ມະປະສິດທິພາບທີ່ບໍ່ເຮັດໃຫ້ User ນັ່ງງົງໃນ App ຂອງເຮົາ, ເຮົາກໍ່ຕ້ອງຮູ້ຈັກວິທີຂຽນ Web ຫຼື App ທີ່ດີໃນລະດັບໜຶ່ງເລີຍ ແລະ ສິ່ງທີ່ຕ່າງໄປຈາກການຂຽນ web/app ແບບເດີມກໍ່ຈະມີຢູ່ 2 ສ່ວນຫຼັກໆຄື: ເຮັດໃຫ້ web/app ຂອງເຮົາວຽກຮ່ວມກັບ blockchain ແລະ ສ່ວນທີ່ເຮັດວຽກຮ່ວມກັບ wallet. ໃນການທີ່ຈະ integrate blockchain ກັບ web/app ເຮົາຕ້ອງໄດ້ອາໄສ Javascript library ເຊັ່ນ: Web3.js ແລະ Ethers.js ສ່ວນຈະເລືອກໃຊ້ອັນໃດນັ້ນກໍ່ຕ້ອງໄປພິຈາລະນາກັນເອົາເອງ.

Wallet ແມ່ນຫຍັງ?
ເຊື່ອວ່າຫຼາຍຄົນກໍ່ຄົງຈະເຄີຍໃຊ້ wallet ຜ່ານມາແລ້ວ ແລະ ແນ່ນອນວ່າການທີ່ຈະ interact ກັບ blockchain ເຮົາຕ້ອງມີ wallet ຢ່າງໜ້ອຍ 1 wallet. ເຊິ່ງ wallet ຈະຊ່ວຍໃນການແລກປ່ຽນສິນຊັບດິຈິຕອນໄດ້ຢ່າງວ່ອງໄວ ແລະ ແຕ່ລະ transactions ທີ່ເກີດຂຶ້ນຈະມີການເຂົ້າລະຫັດ ເຮັດໃຫ້ມີຄວາມປອດໄພຂ້ອນຂ້າງສູງ. wallet ເຊິ່ງສາມາດເຂົ້າເຖິງໄດ້ຈາກທັງມືຖື ແລະ ເວັບຈະຮັກສາຂໍ້ມູນປະຈຳຕົວ ແລະ ຄວາມເປັນສ່ວນຕົວຂອງຜູ້ໃຊ້, ນອກຈາກນີ້ຍັງມີຄຸນສົມບັດທີ່ຈຳເປັນໃນການແລກປ່ຽນ ແລະ ການໂອນລະຫວ່າງແຕ່ລະຝ່າຍທີ່ມີຄວາມປອດໄພ. ຄ້າຍກັບຄວາມສາມາດໃນການສົ່ງ/ຮັບເງິນຂອງ Paypal ຫຼື CashApp ຕ່າງແຕ່ຈະເປັນການສົ່ງ/ຮັບ cryptocurrency ແທນ.

ຖ້າຈະໃຫ້ນັບ wallet ໃນທ້ອງຕະຫຼາດທຸກມື້ນີ້ຖືວ່າມີຫຼາຍເຈົ້າພໍສົມຄວນ, ສ່ວນຕົວແມ່ນແນະນຳໃຫ້ລອງຮຽນ integrate dApp ຂອງເຮົາກັບ Metamask ກ່ອນ, ເນື່ອງຈາກຄົນໃຊ້ຫຼາຍ ແລະ ຫາຂໍ້ມູນງ່າຍ. ອີກອັນໜຶ່ງທີ່ແນະນຳກໍ່ຈະເປັນ WalletConnect ໂຕນີ້ຈະຊ່ວຍໃຫ້ເຮົາສາມາດ connect ກັບ wallet ອື່ນໆໄດ້.
ຮຽນນຳໃຊ້ web3.js ຫຼື ethers.js connect ກັບ dApp ຂອງເຮົາ
ເປັນຫຍັງຄືແນະນຳແຕ່ 2 ໂຕນີ້ເປັນຫຼັກ, ເຫດຜົນກໍ່ບໍ່ມີຫຍັງຫຼາຍເກີນກວ່າການທີ່ມັນເປັນ Javascript library ທີ່ຍອດຮິດນີ້ລ່ະ ສ່ວນອີກເຫດຜົນກໍ່ຄືເຮົາຫາຂໍ້ມູນກ່ຽວກັບການໃຊ້ງານ 2 lib ນີ້ງ່າຍ.

web3.js - ເປັນ collection ຂອງ libraries ທີ່ອະນຸຍາດໃຫ້ເຮົາສາມາດ connect ກັບ local ຫຼື remote Ethereum node ຜ່ານ HTTP, WebSocket ແລະ communication protocols ອື່ນໆໂດຍກົງຈາກ JavaScript Based front-end.
ethers.js - ເປັນ lightweight javascript library ທີ່ເປັນອີກທາງເລືອກໜຶ່ງນອກຈາກ web3.js ໃນການ build javascript frontend ແລະ interact ກັບ Ethereum blockchain.

Resource ທີ່ໜ້າສົນໃຈໃນການສຶກສາດ້ານນີ້

ເຮົາມີ discord community ນ້ອຍໆທີ່ເຮົາຈະລົມກັນເລື່ອງສັບເພເຫລະກັນຢູ່ໃນນັ້ນ, ຖ້າໃຜສົນໃຈເຂົ້າໄປເຮັດໃຫ້ community ເຮົາຄຶກຄື້ນ ແລະ ອຶກກະທຶກຕຶກໂຄມໄປນຳກັນ ລິ້ງດ້ານລຸ່ມ:
*LocalCode**

ref: The Roadmap: Breaking into Web 3.0

DESIGN PATTERNS

phatsss — Tue, 27 Dec 2022 05:52:25 +0000

What's a design pattern?

Design patterns ເປັນວິທີແກ້ໄຂບັນຫາທົ່ວໄປທີ່ມັກເກີດໃນຂະບວນການພັດທະນາ software, ເຊິ່ງປຽບເໝືອນພິມຂຽວ(blueprint)ທີ່ສ້າງ ຫຼື ອອກແບບໄວ້ລ່ວງໜ້າເຊິ່ງເຮົາສາມາດປັບແຕ່ງເພື່ອແກ້ໄຂບັນຫາທີ່ເກີດຊ້ຳໆໃນ code ຂອງເຮົາໄດ້.

ເຮົາບໍ່ສາມາດຄົ້ນຫາ pattern ໃນເນັດ ແລະ copy ມາໃສ່ program ຂອງເຮົາຕົງໆແບບເສກຄາຖາໃສ່ code ໄດ້, ເຊິ່ງມັນບໍ່ຄືກັນກັບການ copy code ຈາກເນັດມາໃສ່ໃນ function ຖ້າເຮັດວຽກໄດ້ແລ້ວຈົບ. pattern ບໍ່ແມ່ນຮູບແບບຂອງ code ສ່ວນໃດສ່ວນໜຶ່ງ ແຕ່ມັນເປັນແນວຄິດໃນການແກ້ໄຂບັນຫາສະເພາະເຈາະຈົງ, ເຊິ່ງເຮົາສາມາດປະຕິບັດຕາມຮູບແບບຂອງແຕ່ລະ pattern ເພື່ອໃຊ້ແກ້ໄຂບັນຫາຕົວຈິງຂອງ program.

ຫຼາຍຄົນມັກຈະສັບສົນລະຫວ່າງ pattern ແລະ algorithms ເນື່ອງຈາກ concept ທັງສອງແມ່ນອະທິບາຍວິທີການແກ້ໄຂບັນຫາບາງບັນຫາທີ່ຮູ້ແລ້ວ. ໃນຂະນະທີ່ algorithms ຈະກຳນົດວິທີການແກ້ໄຂບັນຫາເພື່ອບັນລຸເປົ້າໝາຍໄດ້ຢ່າງຊັດເຈນ(ມີຮູບແບບໃນການຂຽນ code ຊັດເຈນ), ແຕ່ pattern ເປັນຄຳອະທິບາຍວິທີການແກ້ໄຂບັນຫາໃນລະດັບສູງ, ເຊິ່ງ code ທີ່ນຳໃຊ້ pattern ດຽວກັນແຕ່ຢູ່ຄົນລະ projects, code ສ່ວນນັ້ນກໍ່ອາດຈະຕ່າງກັນ.

ຖ້າຈະປຽບທຽບ algorithms ກໍ່ຄືສູດການເຮັດອາຫານ:ເຊິ່ງທັງສອງຈະກຳນົດວິທີການໄວ້ຢ່າງຊັດເຈນເພື່ອໃຫ້ໄດ້ຜົນລັບຕາມເປົ້າໝາຍທີ່ວາງໄວ້. ໃນຂະນະທີ່ pattern ປຽບເໝືອນພິມຂຽວ: ເຊິ່ງເຮົາສາມາດເບິ່ງຜົນລັບ ແລະ ຄຸນລັກສະນະຂອງມັນໄດ້ວ່າເປັນແບບໃດ, ແຕ່ລຳດັບຂອງການໃຊ້ງານແມ່ນຂຶ້ນຢູ່ກັບເຮົາ.

What does the pattern consist of?

pattern ສ່ວນໃຫຍ່ແມ່ນໄດ້ອະທິບາຍຄຸນລັກສະນະໄວ້ພໍປະມານເພື່ອໃຫ້ຄົນທີ່ເອົາໄປນຳໃຊ້ສາມາດນຳໄປປັບໃຊ້ໃນໄດ້ໃນຫຼາຍບໍລິບົດ. ແຕ່ມັກຈະຖືກອະທິບາຍໃນຮູບແບບຕ່າງໆດັ່ງນີ້:

Intent(ເຈດຕະນາ)ຂອງ pattern ຈະອະທິບາຍທັງບັນຫາ ແລະ ແນວທາງແກ້ໄຂບັນຫາ.
Motivation(ແຮງຈູງໃຈ)ຈະອະທິບາຍບັນຫາເພີ່ມເຕີມ ແລະ ແນວທາງແກ້ໄຂທີ່ pattern ເຮັດໃຫ້ເປັນໄປໄດ້.
Structure(ໂຄງສ້າງ)ຂອງ classes ສະແດງແຕ່ລະສ່ວນຂອງ pattern ແລະ ຄວາມກ່ຽວຂ້ອງກັນ.
Code example(ຕົວຢ່າງ Code)ໃນພາສາການຂຽນໂປຣແກຣມຍອດນິຍົມພາສາໜຶ່ງຊ່ວຍໃຫ້ເຂົ້າໃຈແນວຄິດເບື້ອງຫຼັງຂອງ pattern ໄດ້ງ່າຍຂຶ້ນ.

Why should I learn patterns?

ໃນຄວາມເປັນຈິງກໍ່ຄືເຈົ້າກໍ່ອາດຈະເປັນໂປຣແກຣມເມີຄົນໜຶ່ງທີ່ເຮັດວຽກມາຫຼາຍປີໂດຍທີ່ຍັງບໍ່ຮູ້ຈັກ pattern ໃດເລີຍ(ຜູ້ຂຽນກໍ່ເປັນໜຶ່ງໃນນັ້ນ) ແລະ ເຊື່ອວ່າຫຼາຍຄົນກໍ່ເປັນຈັ່ງຊັ້ນ ຫຼື ອາດຈະໃຊ້ຢູ່ແລ້ວແຕ່ບໍ່ຮູ້ວ່າໂຕເອງໃຊ້ຢູ່. ແລ້ວເປັນຫຍັງເຮົາຄືບໍ່ລອງສະລະເວລາມາລອງສຶກສາ pattern ແນ່?

Design pattern ເປັນ toolkit ໃນການແກ້ໄຂບັນຫາທີ່ຜ່ານການທົດລອງ ແລະ ທົດສອບສຳລັບບັນຫາທົ່ວໄປໃນການອອກແບບ software ເຖິງແມ່ນວ່າເຮົາຈະບໍ່ເຄີຍພົບບັນຫາເຫຼົ່ານັ້ນມາກ່ອນ ແຕ່ການທີ່ເຮົາໄດ້ສຶກສາ pattern ມັນກໍ່ຍັງມີປະໂຫຍດ, ເພາະມັນສອນວິທີແກ້ໄຂບັນຫາທຸກປະເພດໂດຍໃຊ້ຫຼັກການອອກແບບເຊີງວັດຖຸ(object-oriented design)
Design patterns ມີການກຳນົດພາສາທົ່ວໄປທີ່ເຮົາ ແລະ ເພື່ອນຮ່ວມທີມສາມາດໃຊ້ເພື່ອສື່ສານກັນໄດ້ຢ່າງມີປະສິດທິພາບຫຼາຍຂຶ້ນ.

*ໃນຄວາມເປັນຈິງຖ້າຈະເອົາມານຳໃຊ້ເຂົ້າໃນຂະບວນການພັດທະນາກໍ່ຕ້ອງຄຳນຶງເຖິງຫຼາຍໆປັດໄຈ, ບາງຄັ້ງມັນກໍ່ອາດຈະບໍ່ເໝາະ.

ບົດຄວາມນີ້ສະຫຼຸບຈາກເວັບໄຊ refactoring.guru

Naming Things

phatsss — Fri, 18 Nov 2022 04:40:57 +0000

ໃນຂະບວນການຂອງການພັດທະນາໂປຣເຈັກໃດໜຶ່ງນອກຈາກຈະມີ Architecture ທີ່ດີ ແລະ ທີມທີ່ມີຄຸນນະພາບແລ້ວ(ແລະ ຕ້ອງເທ້ໆແນ່ຈັກໜ້ອຍ) ສິ່ງໜຶ່ງທີ່ລະເລີຍບໍ່ໄດ້ເລີຍກໍ່ຄົງຈະແມ່ນມາດຕະຖານໃນການພັດທະນາ, ເຊິ່ງມາດຕະຖານໃນການພັດທະນາສຳລັບແຕ່ລະທີມ ຫຼື ແຕ່ລະອົງກອນກໍ່ອາດຈະໃຊ້ບໍ່ຄືກັນ, ສິ່ງໜຶ່ງທີ່ຂ້ອນຂ້າງຈະເປັນບັນຫາສຳລັບເຫຼົ່າ developer ຫຼາຍໆຄົນກໍ່ຄົງຈະມີການຕັ້ງຊື່ຕົວປ່ຽນນີ້ລ່ະ ມັນອາດຈະເບິ່ງຄືເປັນບັນຫານ້ອຍໆທີ່ຫຼາຍຄົນເບິ່ງຂ້າມ ແຕ່ມັນກໍ່ສ້າງຄວາມລຳຄານໃຈໃຫ້ຄົນໃນທີມບໍ່ຫຼາຍກໍ່ໜ້ອຍເລີຍແຫຼະ.

ເມື່ອລອງຊອກຂໍ້ມູນປະມານວ່າ: "ໜ້າວຽກທີ່ຍາກທີ່ສຸດຂອງບັນດານັກພັດທະນາ" ພົບວ່າການຕັ້ງຊື່ອີ່ຫຍັງບາງຢ່າງຈະຕິດໜຶ່ງໃນນັ້ນສະເໝີ(ບາງເທື່ອຂ້ອຍເອງກະໃຊ້ເວລາໃນການຕັ້ງຊື່ຟັງຊັ່ນ ຫຼື ຕົວປ່ຽນດົນກວ່າການຂຽນຟັງຊັ່ນໂດຍລວມອີກ ຮະຮະຮ່າາາາ), ດັ່ງນັ້ນ ເຮົາມາເບິ່ງວິທີການຕັ້ງຊື່ຕົວປ່ຽນໃຫ້ອ່ານງ່າຍ ແລະ ເປັນມາດຕະຖານໃຫ້ກັບທີມໃນການພັດທະນາກັນດີກວ່າ.

ກ່ອນອື່ນໝົດ, ຢຸດຕັ້ງຊື່ທີ່ມັນບໍ່ໄດ້ສື່ຄວາມໝາຍໃດໆໄດ້ແລ້ວ
ຕົວຢ່າງ:

ຊື່ທີ່ຍອດນິຍົມເຊັ່ນ:

var foo, bar

ຊື່ທີ່ເຊີຍທີ່ສຸດເຊັ່ນ: data

const data1, data_1

ຊື່ທີ່ເປັນຄຳຫຍໍ້ພໍເຊົາໄດ້ກະເຊົາ(ຍົກເວັ້ນ id)ເຊັ່ນ:

let acc
let pos
let auth
let mod
let inq

ຈຳພວກ local variable ທັງຫຼາຍກໍ່ເຊົາຕັ້ງຊື່ສັ້ນພຽງ 1 ຕົວອັກສອນໄດ້ແລ້ວເຊັ່ນ:

let i,j,k,x,y,z
//ຢ່າມາບອກວ່າໃຊ້ 2 ຕົວອັກສອນລຽງກັນແລ້ວຊິລອດໃດ, ກອງຢູ່ນຳກັນນີ້ແຫຼະ
let xx,yy,zz

ອີກຂໍ້ທີສຳຄັນ ແລະ ພົບຫຼາຍເລີຍກໍ່ແມ່ນ: ການສະກົດຄຳສັບຜິດໆໃນການຕັ້ງຊື່(ແນະນຳລົງ spell check extendsion ໄວ້)

ຍັງບໍ່ໝົດພຽງເທົ່ານີ້, paper ຫົວຂໍ້ Linguistic antipatterns: what they are and how developers perceive them ໄດ້ອະທິບາຍເຖິງບັນຫາທີ່ເກີດຂຶ້ນຊ້ຳໆໃນການພັດທະນາ software ເຊັ່ນ: ການຕັ້ງຊື່, ເອກະສານ ແລະ ການອະທິບາຍໜ້າທີ່ການເຮັດວຽກຂອງລະບົບ ເຊິ່ງໄດ້ສະຫຼຸບໄວ້ 17 ຂໍ້ດັ່ງນີ້:

Getter method ເຮັດວຽກຫຼາຍກວ່າການ return ຄ່າກັບມາໂດຍບໍ່ມີເອກະສານມາອະທິບາຍ
isXXX method ທຳການ return ຄ່າອື່ນໆທີ່ບໍ່ແມ່ນ boolean
Setter method ທຳການ return ຄ່າກັບອອກມາໄດ້
ຊື່ຂອງ method ບອກວ່າ return ຄ່າພຽງຄ່າດຽວ, ແຕ່ໃນຄວາມເປັນຈິງພັດສົ່ງ List/Array ຫຼື Null ອອກມາເຊັ່ນ List getUser()
Comment ຂອງ method ບອກວ່າມີເງື່ອນໄຂນັ້ນນີ້, ແຕ່ໃນ code ພັດບໍ່ມີ
ໃນ method ມັກຈະມີການ validate ຂໍ້ມູນ, ແຕ່ບໍ່ແຈ້ງຄວາມຜິດພາດໃດໆອອກມາເລີຍ ເຮັດວຽກໄດ້ໃນກໍລະນີທີ່ສຳເລັດເທົ່ານັ້ນໂດຍທີ່ບໍ່ມີເອກະສານໃດມາອະທິບາຍ
Getter method ບໍ່ທຳການ return ຄ່າຫຍັງເລີຍ
ຊື່ຂອງ method ບໍ່ສື່ເຖິງການເຮັດວຽກຕົວຈິງເຊັ່ນ: void isValid()
method ທີ່ທຳການແປງຄ່າຈາກຄ່າໜຶ່ງໄປເປັນອີກຄ່າໜຶ່ງ ບໍ່ທຳການ return ຄ່າອອກມາ
ຊື່ຂອງ method ບອກວ່າ return ຄ່າຫຼາຍກວ່າ 1 ຕົວເຊັ່ນ: List/Array ແຕ່ໃນຄວາມເປັນຈິງພັດສົ່ງຄ່າດຽວກັບມາເຊັ່ນ: int getUsers()
ຊື່ method ກັບຊະນິດຂອງການ return ຂັດແຍ່ງກັນ
ຊື່ method ກັບ Comment ຂອງ method ຂັດແຍ່ງກັນ
ຊື່ຕົວປ່ຽນເປັນເອກະພົດ ແຕ່ມີຄ່າເປັນພະຫູພົດເຊັ່ນ: List User
ຊື່ຕົວປ່ຽນເປັນພະຫູພົດ ແຕ່ມີຄ່າເປັນເອກະພົດເຊັ່ນ: List Users
ຊື່ບອກວ່າເປັນຊະນິດ boolean ແຕ່ຄວາມຈິງພັດບໍ່ແມ່ນ(ເຈົ້າຫຼອກລວງຂ້ອຍ)
ຊື່ ແລະ ຊະນິດຂໍ້ມູນຂອງຕົວປ່ຽນຂັດແຍ່ງກັນ
ຊື່ ແລະ Comment ຂອງຕົວປ່ຽນຂັດແຍ່ງກັນ

ເຮົາລອງມາສຳຫຼວດໂຕເອງເບິ່ງວ່າເຮົາມີພຶດຕິກຳດ້ານເທິງ ຫຼື ບໍ່?, ແຕ່ໂດຍສ່ວນຕົວຜູ້ຂຽນເອງຂໍຮັບບາບໄປເຕັມໆແຕ່ພຽງຜູ້ດຽວ(ຂ້ານ້ອຍຜິດໄປແລ້ວ ງ່າາາາາາາາ)

ແຕ່ເຖິງຢ່າງໃດກໍ່ຕາມຢ່າຟ້າວທໍ້ໃຈເທື່ອ, ທຸກບັນຫາມີທາງເຂົ້າສະເໝີ ເຮົາມາລອງປັບປ່ຽນວິທີການຕັ້ງຊື່ໃຫ້ເປັນມາດຕະຖານຫຼາຍຂຶ້ນ, ເພື່ອເປັນບຸນຕາໃຫ້ແກ່ຜູ້ພົບເຫັນກັນດີກວ່າ.
ຂໍ້ຄວນປະຕິບັດໃນການຊຳລະບາບທັງປວງ

ຕັ້ງຊື່ຕົວປ່ຽນໃຫ້ອ່ານແລ້ວເຂົ້າໃຈ(ໝາຍເຖິງຄົນອື່ນຕ້ອງເຂົ້າໃຈນຳໃດ ບໍ່ແມ່ນເຂົ້າໃຈແຕ່ຜູ້ດຽວ 5555) ຊື່ຂອງຕົວປ່ຽນຄວນຈະອະທິບາຍຈຸດປະສົງຂອງມັນໄດ້ຢ່າງຊັດເຈນ, ຫຼີກລ່ຽງການໃຊ້ຄຳທີ່ອ່ານແລ້ວເຂົ້າໃຈຍາກ *ເລືອກ case ໃນການຕັ້ງຊື່ໃຫ້ເໝາະສົມເຊັ່ນ: camel case ຕົວຢ່າງ:

//bad
const mydate = moment().format("YYYY/MM/DDD")

//good
const currentDate = moment().format("YYYY/MM/DDD")

ຕັ້ງຊື່ຕົວປ່ຽນໃຫ້ Search ໄດ້ງ່າຍ ບາງບົດຄວາມອາດຈະບອກວ່າ: ຢ່າສ້າງຕົວປ່ຽນໃນເມື່ອເຮົາກໍ່ສາມາດໃຊ້ Monomorphic Forms ໄດ້, ເຊິ່ງເຮົາບໍ່ຄວນທີ່ຈະຂະຫຍາຍສິ່ງເຫຼົ່ານີ້ເພື່ອໃຊ້ Constants ເພາະຈະເຮັດໃຫ້ code ອ່ານຍາກ ແລະ search ຍາກຂຶ້ນ, ແຕ່ສິ່ງທີ່ຄວນເຮັດກໍ່ຄື ເກັບຄ່າເຫຼົ່ານັ້ນໄວ້ໃນຕົວປ່ຽນ const ແລະ ໃຊ້ CONSTANT_CASE ໃນການຕັ້ງຊື່ຕົວປ່ຽນ. ຕົວຢ່າງ:

// 86400000 ຄືອີ່ຫຍັງກ່ອນ?
setTimeout(blastOff, 86400000)

//ປະກາດຕົວປ່ຽນ constant ດ້ວຍຕົວອັກສອນໃຫຍ່
const MILLISECONDS_PER_DAY = 60 * 60 * 24 * 1000 //86400000
setTimeout(blastOff, MILLISECONDS_PER_DAY)

ຫຼີກລ່ຽງການຕັ້ງຊື່ຕົວປ່ຽນທີ່ຕ້ອງໄດ້ຄາດເດົາ ມັນຈະເປັນການດີທີ່ເຮົາຈະຕັ້ງຊື່ຕົວປ່ຽນໃຫ້ຊັດເຈນພາຍໃນ array.forEach() ແທນທີ່ຈະໃຊ້ຕົວຫຍໍ້ທີ່ບໍ່ສື່ຄວາມໝາຍໃດໆເລີຍ, ເຊິ່ງແນ່ນອນວ່າມັນອາດຈະແຈກຢາພາລາໃຫ້ພາຍຫຼັງກໍ່ເປັນໄດ້.

//bad
const Car = {
 carMake: "Honda",
 carModel: "Civic",
 carColor: "Gray"
}
const paintCar = (car, color) => {
 car.carColor = color
}

//good
const Car = {
 make: "Honda",
 model: "Civic",
 color: "Gray"
}
const paintCar = (car, color) => {
 car.color = color
}

ຫຼີກລ່ຽງສິ່ງທີ່ບໍ່ຈຳເປັນ ຖ້າຫາກຊື່ Class ຫຼື Object ບົ່ງບອກຢູ່ແລ້ວວ່າພວກມັນຫຍໍ້ມາຈາກຫຍັງ ກໍ່ບໍ່ຈຳເປັນທີ່ຈະຕ້ອງເພີ່ມຂໍ້ມູນນັ້ນລົງໃນຊື່ຕົວປ່ຽນອີກ. ຈາກຕົວຢ່າງດ້ານລຸ່ມ: ເຮົາຮູ້ຢູ່ແລ້ວວ່າເຮົາກຳລັງເວົ້າເຖິງ Car ຫຼື paintCar ດັ່ງນັ້ນ ເຮົາກໍ່ບໍ່ຈຳເປັນທີ່ຈະຕ້ອງເພີ່ມຄຳວ່າ car ໃນຕົວປ່ຽນຊ້ຳອີກຮອບ.

//bad
const Car = {
 carMake: "Honda",
 carModel: "Civic",
 carColor: "Gray"
}
const paintCar = (car, color) => {
 car.carColor = color
}

//good
const Car = {
 make: "Honda",
 model: "Civic",
 color: "Gray"
}
const paintCar = (car, color) => {
 car.color = color
}

ໃຊ້ Default Arguments ໃນ Functions ຫຼີກລ່ຽງການໃຊ້ Short-Circuiting ຫຼື Conditionals ໃນ Functions ເພື່ອເຮັດໃຫ້ Code ຂອງເຮົາ Clean ແລະ ທີ່ສຳຄັນກວ່ານັ້ນຄື: ຈົ່ງຈື່ໄວ້ວ່າ ສະເພາະ Undefined Arguments ເທົ່ານັ້ນທີ່ຈະໄດ້ຮັບຄ່າໂດຍ Function ຂອງເຮົາ Default Values ຈະບໍ່ແທນທີ່ Falsy Values ອື່ນໆ.

//bad
const createMicrobrewery = (name) => {
 const breweryName = name || "Home Brew Co."
 // ...
}

//good
const createMicrobrewery = (name = "Home Brew Co.") => {
 // ...
}

ໃຊ້ Default Arguments ຢ່າງຊານສະຫຼາດ ຕາມກົດເກນທົ່ວໄປແມ່ນ ໃຫ້ຈຳກັດຈຳນວນ Arguments ຂອງ Function ໄວ້ປະມານ 2-3 Arguments. ຫາກມີການຮັບ Arguments ເປັນຈຳນວນຫຼາຍກໍ່ອາດຈະມີຄວາມເປັນໄປໄດ້ທີ່ Function ຂອງເຮົາອາດຈະເຮັດວຽກຫຼາຍຢ່າງເກີນໄປ, ແຕ່ຖ້າຫາກຢາກໃຊ້ຫຼາຍ Arguments ແມ່ນແນະນຳໃຫ້ໃຊ້ JS Object ເປັນ Argument ເພື່ອໃຫ້ເກີດຄວາມຊັດເຈນວ່າມີ Properties ໃດແດ່ທີ່ Function ຕ້ອງການ ແລະ ເຮົາສາມາດໃຊ້ ES6 Destructuring Syntax ໄດ້.

//bad
const createMenu = (title, body, buttonText, cancellable) => {
 // ...
}

createMenu("Foo","Bar","Baz",true)

//good
const createMenu = ({title, body, buttonText, cancellable}) => {
 // ...
}

createMenu({
title: "Foo",
body: "Bar",
buttonText: "Baz",
cancellable: true
})

ແຕ່ລະ Functions ຄວນເຮັດໜ້າທີ່ພຽງຢ່າງດຽວ ຢ່າລືມວ່າ Functions ໃດມີໄວ້ເພື່ອເຮັດຫຍັງ, ໝາຍຄວາມວ່າພະຍາຍາມຂຽນ Code ຂອງເຮົາໃຫ້ເປັນ Module ແລະ ພະຍາຍາມຂຽນ Function ໃຫ້ມີຂະໜາດນ້ອຍລົງເພື່ອໃຫ້ມັນເຮັດໜ້າທີ່ຢ່າງໃດຢ່າງໜຶ່ງພຽງຄັ້ງດຽວ, ສິ່ງທີ່ຈະຊ່ວຍໃຫ້ໝັ້ນໃຈໄດ້ວ່າ Code ຂອງເຮົານັ້ນງ່າຍຕໍ່ການ Test ແລະ ທຳຄວາມເຂົ້າໃຈ, ທີ່ສຳຄັນຄືຢ່າຕັ້ງຈຸດປະສົງຫຼາຍໆຢ່າງພາຍໃນ Function ດຽວ.

//bad
const emailClients = (clients) => {
 clients.forEach(client => {
  const clientRecord = database.lookup(client)
  if(clientRecord.isActive()){
   email(client)
  }
})
}

//good
const emailClients = (clients) => {
 clients.filter(isActiveClient).forEach(email)
}

const isActiveClient = (client) => {
 const clientRecord = database.lookup(client)
 return clientRecord.isActive()
}

ຕັ້ງຊື່ Functions ໃຫ້ອ່ານແລ້ວເຂົ້າໃຈ ກວດສອບໃຫ້ແນ່ໃຈວ່າເຮົາຕັ້ງຊື່ Functions ທີ່ສາມາດເຂົ້າໃຈໄດ້ຢ່າງຊັດເຈນວ່າ Functions ນັ້ນໃຊ້ໄວ້ເຮັດຫຍັງ, ການຕັ້ງຊື່ Function ທີ່ມີຄວາມໝາຍບໍ່ຊັດເຈນຈະເຮັດໃຫ້ຄົນທີ່ມາອ່ານ Code ຈະຕ້ອງເບິ່ງຄຳ Definition ແລະ Logic ຂອງ Function ເພື່ອທຳຄວາມເຂົ້າໃຈໜ້າທີ່ຂອງແຕ່ລະ Function, ເຊິ່ງກໍ່ຈະເຮັດໃຫ້ເສຍເວລາຕື່ມໄປອີກ.

//bad
const addToDate = (date, month) => {
 // ...
}

const date = new Date()

//ເວລາເອີ້ນໃຊ້ມັນກໍ່ຍາກທີ່ຈະເຂົ້າໃຈໄດ້ຈາກຊື່ຟັງຊັ່ນວ່າໄດ້ເພີ່ມຫຍັງ
addToDate(date, 1)

//good
const addMonthToDate = (month, date) => {
 // ...
}

const date = new Date()
addMonthToDate(1, date)

ຫຼີກລ່ຽງການໃຊ້ Code ທີ່ຊ້ຳຊ້ອນກັນ, ເຮັດໃຫ້ Code ສັ້ນລົງ ແລະ Clean ຂຶ້ນ
ສິ່ງທີ່ເຮັດໃຫ້ເຈັບຫົວທີ່ສຸດກໍ່ຄື: ມີການໃຊ້ Code ແບບດຽວຊ້ຳໆກັນໃນຫຼາຍໆ Sections ຂອງ Code, ເຊິ່ງມັນມັກຈະເກີດຂຶ້ນເນື່ອງຈາກ Logic ບາງຢ່າງມີການເຮັດວຽກແຕກຕ່າງກັນພຽງເລັກນ້ອຍ, ແຕ່ເຖິງຢ່າງໃດກໍ່ຕາມ ລອງຄິດພາບວ່າຖ້າຫາກເຮົາພົບ Bud ໃນ Logic ເຮົາຕ້ອງໄດ້ນຳໄປແກ້ໃນທຸກໆ Sections.
ບໍ່ຄວນໃຊ້ Flags ເປັນ Function Parameters
ເຫດຜົນທີ່ເຮົາບໍ່ຄວນໃຊ້ Flags ເປັນ Funstion Parameters ມີພຽງຢ່າງດຽວຄື: Function ຂອງເຮົາເຮັດຫຼາຍໜ້າທີ່ ແລະ ໃນຂໍ້ທີ່ຜ່ານມາກໍ່ບອກແລ້ວວ່າມັນເປັນແນວທາງທີ່ບໍ່ຄວນເຮັດ, ດັ່ງນັ້ນ ແນະນຳໃຫ້ແບ່ງ Function ອອກເປັນ 2 Functions ແທນ.

//bad
const createFile = (name, temp) => {
 if(temp){
  fs.create(`./temp/${name}`)
 }else{
  fs.create(name)
 }
}

//good
const createFile = (name) => {
 fs.create(name)
}

const createTempFile = (name) => {
 fs.create(`./temp/${name}`)
}

ອ້າງອີງ:
https://www.somkiat.cc/meaningful-name/
ແລະ
https://www.techstarthailand.com/blog/detail/10-Tips-to-write-cleaner-JavaScript-code/2147

Clean Architecture using React TypeScript

phatsss — Thu, 29 Sep 2022 08:21:10 +0000

Introduction

Architecture ແມ່ນແນວຄິດທີ່ໃຊ້ໄດ້ກັບທຸກໆພາສາຂອງການຂຽນໂປຣແກຣມ, ໝາຍຄວາມວ່າຄວາມເຂົ້າໃຈກ່ຽວກັບ Architecture ນີ້ຈະບໍ່ໄດ້ຈຳກັດສະເພາະໃນບໍລິບົດຂອງພາສາໂປຣແກຣມພຽງຢ່າງດຽວ. ເຮົາຕ້ອງເຂົ້າໃຈແນວຄິດໂດຍທົ່ວໄປຂອງມັນເພື່ອເຂົ້າໃຈເຖິງສາເຫດ ແລະ ປະໂຫຍດຂອງ Architecture ນີ້, ເຊິ່ງວິທີການນີ້ຈະຄ້າຍຄືກັບການອອກແບບ ຫຼື SOLID pattern. ສະຫຼຸບກໍ່ຄືມັນບໍ່ໄດ້ຖືກຄິດຄົ້ນຂຶ້ນມາສຳຫຼັບພາສາໂປຣແກຣມໃດໜຶ່ງ ແຕ່ມັນສາມາດນຳໃຊ້ແນວຄິດນີ້ກັບພາສາອື່ນໆໄດ້ເຊັ່ນກັນກັບແນວຄິດຂອງ OOP.

ໝາຍເຫດ: ເປົ້າໝາຍຫຼັກຂອງ Clean Architecture ແມ່ນເພື່ອໃຫ້ Code ຂອງເຮົາລະອຽດຂຶ້ນ, ບຳລຸງຮັກສາໄດ້ ແລະ ທົດສອບໄດ້. ໃນໂປຣເຈັກນ້ອຍໆຖ້າຫາກເຮົາຂຽນແບບ Pure JS ໄວກວ່າການໃຊ້ Architecture ແລະ /test ກໍ່ບໍ່ຈຳເປັນຕ້ອງຫັນມາໃຊ້(ຖ້າບໍ່ມີຄວາມຈຳເປັນ), ແຕ່ໃນກໍລະນີທີ່ໂປຣເຈັກເຮົາມີຂະໜາດກາງ-ໃຫຍ່ທີ່ເຮັດວຽກຮ່ວມກັບ developer ຫຼາຍໆຄົນ ແລະ ບາງຄັ້ງກໍ່ອາດຈະໄດ້ແກ້ code ຂອງຄົນອື່ນເຮົາກໍ່ຄວນໃຊ້ເທາະ ຈຶ່ງຈະບໍ່ກັບມາເຈັບຫົວຕອນແກ້ Code ຄືນ.

ໂຄງສ້າງທີ່ດີໃນດ້ານຂອງການພັດທະນາໂປຣແກຣມໃດໜຶ່ງຂຶ້ນມາຄວນແບ່ງ UI,Database ແລະ Business Logic ອອກຈາກກັນເພື່ອໃຫ້ຄວາມອິດສະລະຕໍ່ການ Test, ຕົວຢ່າງ: ຖ້າຢາກ test ໃນຝັ່ງຂອງ business logic ກໍ່ບໍ່ຕ້ອງກັງວົນເລື່ອງຂອງ UI ແລະ Database. ແລະ ໃນທາງກັບກັນ ຖ້າຢາກຈະ test ຝັ່ງຂອງ UI ກໍ່ຄວນບໍ່ມີສ່ວນຂອງ Business Logic ແລະ Database ມາກ່ຽວຂ້ອງ. ເມື່ອທຸກສ່ວນຖືກແຍກອອກຈາກກັນຢ່າງອິດສະລະແລ້ວເວລາ requirement ປ່ຽນໄປກໍ່ຈະເຮັດໃຫ້ການເພີ່ມ ຫຼື ແກ້ໄຂໄດ້ງ່າຍເຊິ່ງມັນຈະບໍ່ກະທົບທັງລະບົບ.

ເປັນຫຍັງຈຶ່ງໃຊ້ Architecture?

ຄວາມຈຳເປັນໃນການໃຊ້ Architecture ກໍ່ຄືມັນຈະປະຢັດເວລາໃນລະຫວ່າງການພັດທະນາ, ການບຳລຸງຮັກສາລະບົບ, ການທົດສອບ ແລະ ການຂະຫຍາຍໂປຣເຈັກໃນອະນາຄົດທີ່ໃຊ້ເວລາໃນການພັດທະນາດົນ.
ສະຫຼຸບງ່າຍໆເລີຍກໍ່ຄື: ຖ້າວາງໂຄງບໍ່ດີຕັ້ງແຕ່ເລີ່ມມັນຍິ່ງຈະມີຄ່າໃຊ້ຈ່າຍທີ່ສູງຖ້າຫາກມີການປ່ຽນແປງໃນອະນາຄົດ, ສະນັ້ນຕ້ອງຄິດເຜື່ອອະນາຄົດໄວ້ນຳ.

ຄຳຈຳກັດຄວາມຂອງ Clean Architecture ໂດຍທົ່ວໄປ

ໃນທີ່ນີ້ຈະບໍ່ໄດ້ອະທິບາຍເນື້ອໃນແບບລະອຽດ, ແຕ່ຈະຍົກເອົາແຕ່ປະເດັນຫຼັກໆແບບສັ້ນໆແທນ.

ແນວຄິດຫຼັກທີ່ຢູ່ເບື້ອງຫຼັງຂອງ diagram ນີ້ແມ່ນການແບ່ງ Application ອອກເປັນ layer (ມີຈັກ layer ກໍ່ໄດ້), ໂດຍທີ່ layer ທີ່ຢູ່ຊັ້ນໃນຈະບໍ່ຮູ້ຈັກ layer ທີ່ຢູ່ຊັ້ນນອກ ແລະ ແຕ່ລະ layer ຈະຊີ້ໄປຫາ Layer ທີ່ຢູ່ຊັ້ນໃນ(Outer Layer to Inner Layer). ຍິ່ງ layer ຢູ່ໄກຈາກສູນກາງເທົ່າໃດຍິ່ງເຫັນລາຍລະອຽດກ່ຽວກັບ Application ທີ່ເປັນ “non-business” ຫຼາຍຂຶ້ນເທົ່ານັ້ນ.

ຈາກທີ່ໄດ້ອະທິບາຍມາແລ້ວວ່າໂຄງສ້າງທີ່ດີໃນການພັດທະນາກໍ່ການແຍກສ່ວນຂອງ UI, Database ແລະ Business Logic ອອກຈາກກັນ, ເຊິ່ງ Clean Architecture ກໍ່ຕອບໂຈດໃນຂະບວນການນີ້. ຈະເຫັນໄດ້ວ່າ Clean Architecture ມີການແບ່ງ layer ໄວ້ຢ່າງຊັດເຈນເຮັດໃຫ້ສາມາດ test ໄດ້ງ່າຍ ແລະ Maintance ພາຍຫຼັງໄດ້ງ່າຍອີກນຳ. Clean Architecture ຈະມີຂໍ້ຕົກລົງຮ່ວມກັນຢູ່ວ່າ layer ຊັ້ນນອກຈະປຽບເໝືອນກົນໄກຕ່າງໆ ແລະ layer ຊັ້ນໃນຈະປຽບເໝືອນ policy ຕ່າງໆ, ຖ້າຫາກ layer ຊັ້ນນອກຕ້ອງການ referrence ໄປຫາ layer ຊັ້ນໃນຈະຕ້ອງເຮັດຕາມ policy ທີ່ກຳນົດໄວ້ ໂດຍທີ່ layer ຊັ້ນໃນຈະບໍ່ຮັບຮູ້ເຖິງ layer ທີ່ຢູ່ຊັ້ນນອກໄດ້, ຊື່ຕ່າງໆຂອງ layer ຊັ້ນນອກຈະບໍ່ຖືກອ້າງອີງເຖິງ layer ຊັ້ນໃນ ແລະ layer ຊັ້ນນອກຈະບໍ່ສົ່ງຜົນກະທົບຕໍ່ layer ຊັ້ນໃນ.
ງົງແມ່ນບໍ່? ຂ້ອຍກະງົງຄືກັນ 🤣🤣🤣, ເພື່ອງົງຕື່ມ ເຮົາໄປຕໍ່ຍາວໆກັນເລີຍ 555

Entities: ເປັນ Layer ຊັ້ນໃນສຸດເຊິ່ງຈະບັນຈຸ business logic ຂອງ Application ແລະ ຈະບໍ່ມີ platform dependencies, ເຊິ່ງ Entities ຈະອະທິບາຍເຖິງ business logic ຂອງ Application ຢ່າງດຽວເທົ່ານັ້ນ.

ຕົວຢ່າງ: ໃນ Class ຂອງ "cart" ເຮົາສາມາດເພີ່ມ item, ລຶບ item, etc. ເຊິ່ງໃນ Layer ນີ້ຈະບໍ່ກ່ຽວກັບບັນດາເຟຣມເວີກຕ່າງໆທີ່ເຮົາໃຊ້ເຊັ່ນ React, Databases ເລີຍ.

ປລ. platform dependencies ຂ້າງເທິງແມ່ນເວົ້າສະເພາະເຈາະຈົງເຖິງບັນດາ libraries ຕ່າງໆເຊັ່ນ: React, Angular, Express, etc. ແມ່ນຈະບໍ່ໄດ້ເອີ້ນໃຊ້ໃນ Layer ນີ້.

ສະຫຼຸບແບບ 5 ວິ: Entities ປຽບເໝືອນ Data Model ຂອງເຮົາທີ່ຈຳແນກວ່າ Data ເຮົາຈະເກັບຫຍັງແນ່ ແລະ ມີ Structure ແນວໃດ.

Use cases: ໃນ layer ທີ 2 ຂອງ diagram ນີ້ຈະບັນຈຸ use cases(Interactors). Use cases ແມ່ນສ່ວນທີ່ອະທິບາຍເຖິງວິທີການໂຕ້ຕອບກັບ Entities ໃນບໍລິບົດຂອງ Application ຂອງເຮົາ.

ຕົວຢ່າງ: ຖ້າຫາກ Entity ຂອງ cart ຮູ້ຈັກພຽງແຕ່ວ່າໂຕມັນເອງສາມາດເພີ່ມ item, ໃນທີ່ນີ້ use case ເຮົາກໍ່ຮູ້ວ່າມັນສາມາດນຳເອົາ item ຈາກ cart ແລະ ສົ່ງ item ເຫຼົ່ານັ້ນໄປສູ່ repository.

ສະຫຼຸບແບບ 5 ວິ: Use cases ເປັນສ່ວນທີ່ເກັບ Business Logic ຕ່າງໆແລ້ວເອີ້ນໃຊ້ Entity ອີກເທື່ອໜຶ່ງ.

Gateways, Presenters, etc. ໃນທີ່ນີ້ Gateways = Repositories, Presenters = View Models. ເຊິ່ງເປັນ layer ທີ່ມີໜ້າທີ່ໃນການເຊື່ອມຕໍ່ລະຫວ່າງ business rules ຂອງ application ແລະ platform ສ່ວນຕ່າງໆຂອງລະບົບ.

ຕົວຢ່າງ: repositories ຈະມີ interface ທີ່ມີການ implement classes ໄວ້ເພື່ອ access APIs ຫຼື repositories ແລະ View Model interface ຈະໃຊ້ເພື່ອເຊື່ອມຕໍ່ກັບ React Component ດ້ວຍການເອີ້ນໃຊ້ business logic.

ປລ. ໃນຕົວຢ່າງຂອງເຮົາ Use cases ແລະ Repositories ຈະຢູ່ໃນລຳດັບທີ່ແຕກຕ່າງກັນ ເພາະວ່າການເຮັດວຽກສ່ວນໃຫຍ່ຂອງ front-end ແມ່ນຮັບ ແລະ ສົ່ງ data ຜ່ານ API ເປັນຫຼັກ.

ສະຫຼຸບແບບ 5 ວິ:ອາດເວົ້າໄດ້ວ່າ layer ນີ້ແມ່ນສ່ວນທີ່ເອົາໄວ້ແປງຮູບແບບຂອງຂໍ້ມູນເຊັ່ນ ຢາກແປງຮູບແບບຂໍ້ມູນຈາກ format ໃດໆກໍ່ຕາມໃຫ້ເປັນ format ທີ່ application ເຮົາເຂົ້າໃຈ ແລະ ໃຊ້ໄດ້ງ່າຍ. ຕົວຢ່າງ ແປງຈາກ json format ເປັນ object ທີ່ເຮົາຕ້ອງການ, ເຊິ່ງເຮົາເອີ້ນສິ່ງທີ່ເຮົາໜ້າທີ່ເຫຼົ່ານີ້ວ່າ Adapter.

External interfaces: ເປັນ platform dependent layer, ໃນຊັ້ນນີ້ເຮົາຈະເຫັນການ direct access ໄປ API, React Components, etc. ມັນເປັນ layer ທີ່ຍາກໃນການ test ແລະ build abstraction.

ສະຫຼຸບແບບ 5 ວິ: layer ນີ້ເປັນສ່ວນທີ່ຈັດການກັບ framework ທີ່ເຮົາໃຊ້ໃນໂປຣເຈັກ ໃນສ່ວນນີ້ເຮົາອາດຈະບໍ່ໄດ້ຂຽນ code ຫຼາຍແຕ່ກໍ່ເປັນສ່ວນທີ່ສຳຄັນເພາະເປັນສ່ວນທີ່ເອົາໄວ້ໃຊ້ຕິດຕໍ່ກັບ framework ຕ່າງໆທີ່ເຮົາໃຊ້ເຊັ່ນ: ການຂຽນ code ເພື່ອສ້າງ database connection ເປັນຕົ້ນ.

Clean Architecture ສຳຫຼັບ frontend

ຖ້າອ່ານຫົວຂໍ້ດ້ານເທິງແລ້ວຍັງບໍ່ເຫັນພາບເທື່ອ, ເຮົາມາລອງເບິ່ງວ່າຖ້າເອົາມາໃຊ້ໃນເບື້ອງຂອງ frontend ແລ້ວ ມັນອອກມາໜ້າຕາແບບໃດ.

Entities: ຄວາມໝາຍຂອງ Entities ກໍ່ຈະຄ້າຍຄືກັບຄຳອະທິບາຍດ້ານເທິງ, ເຊິ່ງ Entities ຈະເປັນວິທີການໃນການເກັບ state ແລະ ສ່ວນໃຫຍ່ກໍ່ມັກໃຊ້ເພື່ອຈຸດປະສົງນີ້ເປັນຫຼັກ.
Repository interfaces: ເປັນ Interfaces ທີ່ໃຊ້ເພື່ອເຂົ້າເຖິງ API, database, storages, etc. ມັນອາດຈະເບິ່ງຄືແປກໆທີ່ interfaces ຈະຢູ່ layer ຊັ້ນໃນກວ່າ use case, ເຖິງຢ່າງໃດກໍ່ຕາມໃນບໍລິບົດຂອງການໃຊ້ງານສະແດງໃຫ້ເຫັນວ່າ use case ຈະຮູ້ repositories ແຕ່ repositories ຈະບໍ່ຮູ້ຫຍັງກ່ຽວກັບ layer ຂອງ use case ເລີຍ ແລະ repositories ພັດຮູ້ກ່ຽວກັບ entities ນີ້ຈຶ່ງເປັນສາເຫດທີ່ເຮັດໃຫ້ interfaces ຢູ່ໃນ layer ນີ້.
Use Cases: ຄວາມໝາຍຂອງ use case ກໍ່ແມ່ນແບບດຽວກັນກັບດ້ານເທິງຄື Objects ທີ່ຈະນຳໃຊ້ໃນການ implement business logic ໃນບໍລິບົດຂອງ Application ຂອງເຮົາ(ຮູ້ວ່າຈະເຮັດຫຍັງກັບ entities ເຊັ່ນ: send, upload, filter, merge)
View Models ແລະ View Interfaces:

View Model - ແມ່ນໃຊ້ທົດແທນ Presenters ຈາກ diagram ທີ 1. ໃນໂປຣເຈັກຂອງເຮົາຈະໃຊ້ MVVP Architecture(instead of MVP\MVC\MV*), ອະທິບາຍໂດຍຫຍໍ້ຄື: ຄວາມແຕກຕ່າງຂອງ MVVP ມີພຽງຢ່າງດຽວຄື: Presenter ຈະຮູ້ກ່ຽວກັບ View ແລະ ວິທີການເອີ້ນ method ຂອງມັນ, ແຕ່ ViewModel ບໍ່ຮູ້ຈັກ View ແລະ ມີພຽງ method ດຽວທີ່ notify ເຖິງການປ່ຽນແປງຕ່າງໆ. View ເຮັດໜ້າທີ່ພຽງແຕ່ "monitor" state ຂອງ View Model. ຫຼັກການຂອງ MVVP ແມ່ນຈະເຮັດວຽກໄປໃນທິດທາງດຽວ(View → ViewModel) ໃນຂະນະທີ່ MVP ເຮັດວຽກແບບ 2 ທິດທາງ (View ︎← → Presenter), dependencies ໜ້ອຍລົງ ແລະ test ງ່າຍກວ່າ.
View Interfaces - ໃນກໍລະນີນີ້, ຈະມີໜຶ່ງ class ພື້ນຖານສຳລັບ Views ທັງໝົດ, ໂດຍທີ່ View Model ຈະແຈ້ງເຕືອນ(notify) View ກໍຕໍ່ເມື່ອມີການປ່ຽນແປງໃດໜຶ່ງເກີດຂຶ້ນ. ເຊິ່ງຈະໃຊ້ onViewModelChanged() method ແລະ ນີ້ກໍ່ແມ່ນໜຶ່ງໃນຕົວຢ່າງຂອງ dependency inversion.

External interfaces: ຄວາມໝາຍຂອງຂໍ້ນີ້ກໍ່ເຊັ່ນດຽວກັນກັບ diagram ທີ 1, layer ນີ້ຈະບັນຈຸບັນດາ platform-dependent implementations ຕ່າງໆ. ໃນກໍລະນີທີ່ application ຂອງເຮົາພັດທະນາໂດຍໃຊ້ React components ແລະ implementations interfaces ເພື່ອເຂົ້າເຖິງ API (ຮູບປະກອບດ້ານລຸ່ມ), ເຖິງຢ່າງໃດກໍ່ຕາມໃນ layer ນີ້ເຮົາສາມາດໃຊ້ framework ໃດກໍ່ໄດ້(AngularJS, VueJS, ReactJS, ReactNative, etc.) ແລະ storage ໃດກໍ່ໄດ້(IndexDB, LocalStorage, etc.), ເຊິ່ງ Clean Architecture ຊ່ວຍໃຫ້ເຮົາສາມາດແຍກໃຊ້ສະເພາະ framework, libraries ແລະ technologies ໃດກໍ່ໄດ້. ດັ່ງນັ້ນເຮົາຈຶ່ງສາມາດ test ໄດ້ງ່າຍ ແລະ ຈະປ່ຽນໄປໃຊ້ framework ໃດກໍ່ໄດ້.

arrow ສີແດງແມ່ນສະແດງເຖິງ flow ຂອງ data(ແຕ່ບໍ່ແມ່ນບັນດາ dependencies, dependency diagram ແມ່ນສະແດງຢູ່ diagram ດ້ານເທິງ), ບັນດາ structure ທີ່ກ່າວມາດ້ານເທິງກໍ່ສາມາດປ່ຽນແປງໃຫ້ເໝາະສົມກັບ application ທີ່ເຮົາພັດທະນາ.

ໃນການໃຊ້ງານຈິງເຮົາຈະວາງ Structures ໄດ້ດັ່ງນີ້

data - ບັນຈຸບັນດາ classes ທີ່ໃຊ້ໃນການເຂົ້າເຖິງ data,ຖ້າປຽບທຽບໃສ່ diagram folder ນີ້ຈະເປັນ layer ຊັ້ນໃນສຸດຍ້ອນວ່າງໃນນີ້ຈະມີ classes ສຳລັບ implementing repository interfaces. ດັ່ງນັ້ນ classes ເຫຼົ່ານີ້ຈະຖືກໃຊ້ໃນການເຊື່ອມຕໍ່ກັບ API ແລະ platform dependent(local storage, cookies, etc.)
domain - classes ເຫຼົ່ານີ້ບັນຈຸບັນດາ business logic, ໃນ folder ນີ້ຈະມີ Entities, Use Cases ແລະ Repository Interfaces. ໃນ entities folder ຈະແບ່ງເປັນ 2 folder ຍ່ອຍຄື: models ແລະ structures.
models: ເປັນບັນດາ logic ຕ່າງໆ ແລະ structures ຈະເປັນ data structure.
presentation - folder ນີ້ບັນຈຸ View Models, View Interfaces ແລະ View (framework components).

ຈາກໂຄງສ້າງດ້ານເທິງມັນກໍ່ບໍ່ແມ່ນສິ່ງຕາຍຕົວທີ່ເຮົາຈະຕ້ອງກຳນົດແບບນີ້ເປະໆ, ສະນັ້ນ ເຮົາກໍ່ຕ້ອງປັບໃຊ້ຕາມຈຸດປະສົງ ແລະ ຄວາມເໝາະສົມ.

ສຸດທ້າຍນີ້ກໍ່ຫວັງວ່າບົດຄວາມນີ້ຈະເປັນປະໂຫຍດໃຫ້ແກ້ຜູ້ອ່ານບໍ່ຫຼາຍ ຫຼື ອາດຈະບໍ່ມີເລີຍ 5555, ແຕ່ຖ້າຢາກໃຫ້ຂຽນອະທິບາຍ Code ຕົວຈິງກໍ່ລອງທັກຫຼັງໄມມາ ຫຼື ຖິ້ມເມັ້ນປະໄວ້ດຽວຈະພະຍາຍາມກັບມາຂຽນຕໍ່.

ບົດຄວາມນີ້ຖອດເອົາສະເພາະບາງສ່ວນມາຈາກ The Clean Architecture using React and TypeScript. Part 1: Basics

Replace empty string to undefined value in Object (JS)

phatsss — Wed, 17 Aug 2022 17:48:54 +0000

just create function like:

 const replaceEmpty = (obj) => {
    let newObj = {};
    Object.keys(obj).forEach((key) => {
      if (obj[key] === Object(obj[key])) newObj[key] = removeEmpty(obj[key]);
      else if (obj[key] !== undefined) newObj[key] = obj[key];
      else if (obj[key] === undefined) newObj[key] = '';
    });
    return newObj;
  };

that's all, hope this func can help U 😵‍💫