ບັນທຶກຜູ້ພັດທະນາ Habr front-end: refactoring ແລະສະທ້ອນໃຫ້ເຫັນ

ຂ້າພະເຈົ້າມີຄວາມສົນໃຈສະເຫມີກ່ຽວກັບວິທີການ Habr ມີໂຄງສ້າງຈາກພາຍໃນ, ວິທີການເຮັດວຽກແມ່ນໂຄງສ້າງ, ວິທີການການສື່ສານມີໂຄງສ້າງ, ມາດຕະຖານໃດທີ່ໃຊ້ແລະວິທີການຂຽນລະຫັດໂດຍທົ່ວໄປຢູ່ທີ່ນີ້. ໂຊກດີ, ຂ້ອຍໄດ້ຮັບໂອກາດດັ່ງກ່າວ, ເພາະວ່າບໍ່ດົນມານີ້ຂ້ອຍໄດ້ກາຍເປັນສ່ວນຫນຶ່ງຂອງທີມ habra. ການນໍາໃຊ້ຕົວຢ່າງຂອງ refactoring ຂະຫນາດນ້ອຍຂອງສະບັບມືຖື, ຂ້າພະເຈົ້າຈະພະຍາຍາມຕອບຄໍາຖາມ: ມັນເປັນແນວໃດທີ່ຈະເຮັດວຽກຢູ່ທາງຫນ້າ. ໃນໂຄງການ: Node, Vue, Vuex ແລະ SSR ກັບຊອດຈາກບັນທຶກກ່ຽວກັບປະສົບການສ່ວນຕົວໃນ Habr.

ສິ່ງທໍາອິດທີ່ທ່ານຈໍາເປັນຕ້ອງຮູ້ກ່ຽວກັບທີມງານພັດທະນາແມ່ນວ່າມີຈໍານວນຫນ້ອຍຂອງພວກເຮົາ. ບໍ່ພຽງພໍ - ເຫຼົ່ານີ້ແມ່ນສາມຫນ້າ, ສອງດ້ານຫລັງແລະຫົວຫນ້າດ້ານວິຊາການຂອງ Habr - Baxley ທັງຫມົດ. ແນ່ນອນ, ຍັງມີນັກທົດສອບ, ຜູ້ອອກແບບ, ສາມ Vadim, ດອກແຂມມະຫັດສະຈັນ, ຜູ້ຊ່ຽວຊານດ້ານການຕະຫຼາດແລະ Bumburum ອື່ນໆ. ແຕ່ມີພຽງແຕ່ຫົກຜູ້ປະກອບສ່ວນໂດຍກົງກັບແຫຼ່ງ Habr. ນີ້ແມ່ນຂ້ອນຂ້າງຫາຍາກ - ໂຄງການທີ່ມີຜູ້ຊົມຫຼາຍລ້ານໂດລາ, ເຊິ່ງຈາກພາຍນອກເບິ່ງຄືວ່າວິສາຫະກິດຍັກໃຫຍ່, ໃນຄວາມເປັນຈິງແລ້ວເບິ່ງຄືວ່າເປັນການເລີ່ມຕົ້ນທີ່ສະດວກສະບາຍກັບໂຄງສ້າງອົງການຈັດຕັ້ງທີ່ລຽບງ່າຍທີ່ສຸດ.

ເຊັ່ນດຽວກັນກັບບໍລິສັດໄອທີອື່ນໆຈໍານວນຫຼາຍ, Habr ປະກອບອາຊີບແນວຄວາມຄິດ Agile, ການປະຕິບັດ CI, ແລະນັ້ນແມ່ນທັງຫມົດ. ແຕ່ຕາມຄວາມຮູ້ສຶກຂອງຂ້ອຍ, Habr ເປັນຜະລິດຕະພັນກໍາລັງພັດທະນາຢູ່ໃນຄື້ນຫຼາຍກ່ວາຢ່າງຕໍ່ເນື່ອງ. ດັ່ງນັ້ນ, ສໍາລັບການແລ່ນຫຼາຍໆຄັ້ງຕິດຕໍ່ກັນ, ພວກເຮົາດຸຫມັ່ນລະຫັດບາງສິ່ງບາງຢ່າງ, ການອອກແບບແລະການອອກແບບໃຫມ່, ທໍາລາຍບາງສິ່ງບາງຢ່າງແລະແກ້ໄຂມັນ, ແກ້ໄຂປີ້ແລະສ້າງໃຫມ່, ກ້າວເທິງ rake ແລະຫນໍ່ໄມ້ສ່ວນຫຼາຍຕົວເຮົາເອງຢູ່ໃນຕີນ, ໃນຄໍາສັ່ງທີ່ຈະປ່ອຍຄຸນນະສົມບັດເຂົ້າໄປໃນ. ການຜະລິດ. ແລະຫຼັງຈາກນັ້ນມີ lull ທີ່ແນ່ນອນ, ໄລຍະເວລາຂອງການພັດທະນາຄືນໃຫມ່, ເວລາທີ່ຈະເຮັດສິ່ງທີ່ຢູ່ໃນສີ່ຫລ່ຽມ "ບໍ່ສໍາຄັນ - ບໍ່ຮີບດ່ວນ".

ມັນເປັນທີ່ຊັດເຈນນີ້ "ນອກລະດູການ" sprint ທີ່ຈະໄດ້ຮັບການປຶກສາຫາລືຂ້າງລຸ່ມນີ້. ເວລານີ້ມັນລວມເອົາການ refactoring ສະບັບມືຖືຂອງ Habr. ໂດຍທົ່ວໄປ, ບໍລິສັດມີຄວາມຫວັງສູງສໍາລັບມັນ, ແລະໃນອະນາຄົດມັນຄວນຈະທົດແທນສວນສັດທັງຫມົດຂອງ Habr incarnations ແລະກາຍເປັນການແກ້ໄຂຂ້າມເວທີ. ມື້ຫນຶ່ງຈະມີຮູບແບບການປັບຕົວ, PWA, ໂຫມດອອບໄລນ໌, ການປັບແຕ່ງຜູ້ໃຊ້, ແລະສິ່ງທີ່ຫນ້າສົນໃຈອື່ນໆຈໍານວນຫຼາຍ.

ໃຫ້ກໍານົດວຽກງານ

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

ຂ້າພະເຈົ້າເປັນຫ່ວງຕົ້ນຕໍກ່ຽວກັບປະສິດທິພາບຂອງການນໍາໃຊ້ຊັບພະຍາກອນແລະສິ່ງທີ່ເອີ້ນວ່າການໂຕ້ຕອບກ້ຽງ. ທຸກໆມື້, ໃນເສັ້ນທາງບ້ານ - ເຮັດວຽກ - ເຮືອນ, ຂ້ອຍເຫັນໂທລະສັບເກົ່າຂອງຂ້ອຍພະຍາຍາມສະແດງຫົວຂໍ້ 20 ຫົວຂໍ້ໃນອາຫານ. ມັນເບິ່ງຄືແນວນີ້:

ການໂຕ້ຕອບ Habr ມືຖືກ່ອນທີ່ຈະ refactoring

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

ໂຄງການ SSR-CSR ເກົ່າ. ການອະນຸຍາດແມ່ນເປັນໄປໄດ້ພຽງແຕ່ໃນຂັ້ນຕອນ C3 ແລະ C4, ເມື່ອ Node JS ບໍ່ຫວ່າງທີ່ຈະສ້າງ HTML ແລະສາມາດຮ້ອງຂໍຕົວແທນໄປຫາ API.

ສະຖາປັດຕະຍະກໍາຂອງພວກເຮົາໃນເວລານັ້ນໄດ້ຖືກອະທິບາຍຢ່າງຖືກຕ້ອງໂດຍຫນຶ່ງໃນຜູ້ໃຊ້ Habr:

ສະບັບມືຖືແມ່ນ crap. ຂ້ອຍບອກມັນຄືກັນ. ການປະສົມປະສານທີ່ຂີ້ຮ້າຍຂອງ SSR ແລະ CSR.

ພວກເຮົາຕ້ອງຍອມຮັບມັນ, ບໍ່ວ່າມັນຈະໂສກເສົ້າປານໃດ.

ຂ້າພະເຈົ້າໄດ້ປະເມີນທາງເລືອກ, ສ້າງປີ້ໃນ Jira ດ້ວຍຄໍາອະທິບາຍໃນລະດັບຂອງ "ມັນບໍ່ດີດຽວນີ້, ເຮັດມັນຖືກຕ້ອງ" ແລະທໍາລາຍວຽກງານໃນຈັງຫວະກວ້າງ:

• ນໍາ​ໃຊ້​ຄືນ​ຂໍ້​ມູນ​,
• ຫຼຸດ​ຜ່ອນ​ຈໍາ​ນວນ​ຂອງ redraws ໄດ້​,
• ລົບລ້າງການຮ້ອງຂໍຊ້ໍາກັນ,
• ເຮັດໃຫ້ຂະບວນການໂຫຼດໄດ້ຊັດເຈນຂຶ້ນ.

ມາໃຊ້ຂໍ້ມູນຄືນໃໝ່

ໃນທາງທິດສະດີ, ການສະແດງຜົນຂ້າງເຊີບເວີຖືກອອກແບບເພື່ອແກ້ໄຂບັນຫາສອງຢ່າງ: ບໍ່ໃຫ້ປະສົບກັບຂໍ້ຈໍາກັດຂອງເຄື່ອງຈັກຊອກຫາໃນແງ່ຂອງ. ການສ້າງດັດສະນີ SPA ແລະປັບປຸງ metric FMP (ຢ່າງ​ຫລີກ​ລ້ຽງ​ບໍ່​ໄດ້​ຮ້າຍ​ແຮງ​ຂຶ້ນ​ TTI). ໃນສະຖານະການຄລາສສິກທີ່ສຸດທ້າຍ ສ້າງຂື້ນຢູ່ Airbnb ໃນປີ 2013 ປີ (ຍັງຢູ່ໃນ Backbone.js), SSR ແມ່ນແອັບພລິເຄຊັນ isomorphic JS ດຽວກັນທີ່ເຮັດວຽກຢູ່ໃນສະພາບແວດລ້ອມ Node. ເຄື່ອງແມ່ຂ່າຍພຽງແຕ່ສົ່ງຮູບແບບທີ່ສ້າງຂຶ້ນເປັນການຕອບສະຫນອງຕໍ່ການຮ້ອງຂໍ. ຫຼັງຈາກນັ້ນ, ການ rehydration ເກີດຂຶ້ນໃນດ້ານລູກຄ້າ, ແລະຫຼັງຈາກນັ້ນທຸກສິ່ງທຸກຢ່າງເຮັດວຽກໂດຍບໍ່ມີການໂຫຼດຫນ້າ. ສໍາລັບ Habr, ສໍາລັບຊັບພະຍາກອນອື່ນໆຈໍານວນຫຼາຍທີ່ມີເນື້ອໃນຂໍ້ຄວາມ, ການສະແດງເຄື່ອງແມ່ຂ່າຍເປັນອົງປະກອບທີ່ສໍາຄັນໃນການສ້າງຄວາມສໍາພັນທີ່ເປັນມິດກັບເຄື່ອງຈັກຊອກຫາ.

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

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

ຫນຶ່ງໃນບັນຫາທີ່ເກີດຂື້ນແມ່ນການບໍ່ສາມາດປ່ຽນໂຄງສ້າງຮອບວຽນເປັນ JSON (ກະສານອ້າງອີງວົງ); ໄດ້ຖືກແກ້ໄຂໂດຍການພຽງແຕ່ປ່ຽນໂຄງສ້າງດັ່ງກ່າວກັບຄູ່ຮ່ວມງານຮາບພຽງ.

ນອກຈາກນັ້ນ, ເມື່ອຈັດການກັບເນື້ອຫາ UGC, ທ່ານຄວນຈື່ຈໍາວ່າຂໍ້ມູນຄວນຖືກປ່ຽນເປັນຫນ່ວຍງານ HTML ເພື່ອບໍ່ໃຫ້ທໍາລາຍ HTML. ສໍາລັບຈຸດປະສົງເຫຼົ່ານີ້ພວກເຮົາໃຊ້ he.

ຫຼຸດການແຕ້ມຄືນໃໝ່

ດັ່ງທີ່ທ່ານສາມາດເຫັນໄດ້ຈາກແຜນວາດຂ້າງເທິງ, ໃນກໍລະນີຂອງພວກເຮົາ, ຫນຶ່ງ Node JS instance ປະຕິບັດສອງຫນ້າທີ່: SSR ແລະ "proxy" ໃນ API, ບ່ອນທີ່ການອະນຸຍາດຂອງຜູ້ໃຊ້ເກີດຂື້ນ. ສະຖານະການນີ້ເຮັດໃຫ້ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະອະນຸຍາດໃນຂະນະທີ່ລະຫັດ JS ເຮັດວຽກຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ, ນັບຕັ້ງແຕ່ node ເປັນກະທູ້ດຽວ, ແລະຟັງຊັນ SSR ແມ່ນ synchronous. ນັ້ນແມ່ນ, ເຄື່ອງແມ່ຂ່າຍພຽງແຕ່ບໍ່ສາມາດສົ່ງຄໍາຮ້ອງຂໍໃຫ້ກັບຕົວມັນເອງໃນຂະນະທີ່ callstack ຫຍຸ້ງກັບບາງສິ່ງບາງຢ່າງ. ມັນໄດ້ຫັນອອກທີ່ພວກເຮົາໄດ້ປັບປຸງສະຖານະ, ແຕ່ການໂຕ້ຕອບບໍ່ໄດ້ຢຸດເຊົາການ twitching, ເນື່ອງຈາກວ່າຂໍ້ມູນໃນລູກຄ້າຕ້ອງໄດ້ຮັບການປັບປຸງໂດຍຄໍານຶງເຖິງກອງປະຊຸມຜູ້ໃຊ້. ພວກເຮົາຈໍາເປັນຕ້ອງສອນຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາໃຫ້ຂໍ້ມູນທີ່ຖືກຕ້ອງຢູ່ໃນສະພາບເບື້ອງຕົ້ນ, ໂດຍຄໍານຶງເຖິງການເຂົ້າສູ່ລະບົບຂອງຜູ້ໃຊ້.

ມີພຽງແຕ່ສອງວິທີແກ້ໄຂບັນຫາ:

• ຄັດຕິດຂໍ້ມູນການອະນຸຍາດກັບຄໍາຮ້ອງຂໍຂ້າມເຄື່ອງແມ່ຂ່າຍ;
• ແບ່ງຊັ້ນ Node JS ອອກເປັນສອງຕົວຢ່າງແຍກຕ່າງຫາກ.

ການແກ້ໄຂທໍາອິດຮຽກຮ້ອງໃຫ້ມີການນໍາໃຊ້ຕົວແປທົ່ວໂລກໃນເຄື່ອງແມ່ຂ່າຍ, ແລະອັນທີສອງໄດ້ຂະຫຍາຍເສັ້ນຕາຍສໍາລັບການສໍາເລັດວຽກງານຢ່າງຫນ້ອຍຫນຶ່ງເດືອນ.

ວິທີການເລືອກ? Habr ມັກຈະຍ້າຍອອກໄປຕາມເສັ້ນທາງຂອງການຕໍ່ຕ້ານຢ່າງຫນ້ອຍ. ໂດຍບໍ່ເປັນທາງການ, ມີຄວາມປາຖະໜາທົ່ວໄປທີ່ຈະຫຼຸດວົງຈອນຈາກຄວາມຄິດໄປສູ່ຕົ້ນແບບໃຫ້ໜ້ອຍທີ່ສຸດ. ຮູບແບບຂອງທັດສະນະຄະຕິຕໍ່ຜະລິດຕະພັນແມ່ນ reminiscent ບາງຢ່າງຂອງ postulates ຂອງ booking.com, ມີຄວາມແຕກຕ່າງພຽງແຕ່ວ່າ Habr ໃຊ້ເວລາຄວາມຄິດເຫັນຂອງຜູ້ໃຊ້ຫຼາຍຢ່າງຮຸນແຮງແລະໄວ້ວາງໃຈທ່ານ, ເປັນນັກພັດທະນາ, ໃນການຕັດສິນໃຈດັ່ງກ່າວ.

ປະຕິບັດຕາມເຫດຜົນນີ້ແລະຄວາມປາຖະຫນາຂອງຂ້ອຍເອງທີ່ຈະແກ້ໄຂບັນຫາຢ່າງໄວວາ, ຂ້ອຍເລືອກຕົວແປທົ່ວໂລກ. ແລະ, ດັ່ງທີ່ເກີດຂື້ນເລື້ອຍໆ, ທ່ານຕ້ອງຈ່າຍເງິນໃຫ້ພວກເຂົາໄວຫຼືຫຼັງຈາກນັ້ນ. ພວກເຮົາຈ່າຍເງິນເກືອບທັນທີ: ພວກເຮົາເຮັດວຽກໃນທ້າຍອາທິດ, ລ້າງຜົນສະທ້ອນ, ຂຽນ ຫຼັງຈາກນັ້ນ mortem ແລະເລີ່ມແບ່ງເຄື່ອງແມ່ຂ່າຍອອກເປັນສອງສ່ວນ. ຄວາມຜິດພາດແມ່ນໂງ່ຫຼາຍ, ແລະແມງໄມ້ທີ່ກ່ຽວຂ້ອງກັບມັນບໍ່ງ່າຍທີ່ຈະແຜ່ພັນ. ແລະແມ່ນແລ້ວ, ມັນເປັນຄວາມອັບອາຍສໍາລັບການນີ້, ແຕ່ວິທີການຫນຶ່ງຫຼືອື່ນ, stumbled ແລະ groaning, PoC ຂອງຂ້າພະເຈົ້າກັບຕົວແປທົ່ວໂລກຢ່າງໃດກໍຕາມໄດ້ເຂົ້າໄປໃນການຜະລິດແລະກໍາລັງເຮັດວຽກຂ້ອນຂ້າງສົບຜົນສໍາເລັດໃນຂະນະທີ່ລໍຖ້າສໍາລັບການຍ້າຍໄປສູ່ສະຖາປັດຕະ "ສອງໂຫນດ" ໃຫມ່. ນີ້ແມ່ນບາດກ້າວທີ່ສໍາຄັນ, ເພາະວ່າເປົ້າຫມາຍດັ່ງກ່າວໄດ້ບັນລຸຢ່າງເປັນທາງການ - SSR ໄດ້ຮຽນຮູ້ທີ່ຈະສົ່ງຫນ້າທີ່ກຽມພ້ອມທີ່ຈະນໍາໃຊ້ຢ່າງສົມບູນ, ແລະ UI ໄດ້ກາຍເປັນສະຫງົບຫຼາຍ.

ການໂຕ້ຕອບ Habr ມືຖືຫຼັງຈາກຂັ້ນຕອນທໍາອິດຂອງການ refactoring

ໃນທີ່ສຸດ, ສະຖາປັດຕະຍະກໍາ SSR-CSR ຂອງສະບັບມືຖືນໍາໄປສູ່ຮູບນີ້:

ວົງຈອນ "ສອງໂຫນດ" SSR-CSR. Node JS API ແມ່ນກຽມພ້ອມສະເໝີສໍາລັບ I/O asynchronous ແລະບໍ່ໄດ້ຖືກບລັອກໂດຍຟັງຊັນ SSR, ເນື່ອງຈາກວ່າອັນສຸດທ້າຍແມ່ນຢູ່ໃນຕົວຢ່າງແຍກຕ່າງຫາກ. ລະບົບຕ່ອງໂສ້ການສອບຖາມ #3 ແມ່ນບໍ່ຈໍາເປັນ.

ການລົບລ້າງການຮ້ອງຂໍຊ້ໍາກັນ

ຫຼັງຈາກການຫມູນໃຊ້ໄດ້ຖືກປະຕິບັດ, ການສະແດງເບື້ອງຕົ້ນຂອງຫນ້າເວັບບໍ່ໄດ້ເຮັດໃຫ້ເກີດພະຍາດບ້າຫມູອີກຕໍ່ໄປ. ແຕ່ການໃຊ້ Habr ຕື່ມອີກໃນຮູບແບບ SPA ຍັງເຮັດໃຫ້ເກີດຄວາມສັບສົນ.

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

ການກັບຄືນໄປຫາຟີດໂພສເຮັດໃຫ້ເກີດການຮ້ອງຂໍຂໍ້ມູນໃໝ່

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

ArticlesList: [
  { Article1 },
  ...
],
PageArticle: { ArticleFull1 },

ໃນຈໍານວນທັງຫມົດ, ພວກເຮົາມີໂມດູນ ລາຍຊື່ບົດຄວາມ, ເຊິ່ງປະກອບດ້ວຍວັດຖຸຂອງປະເພດ ບົດຄວາມ ແລະໂມດູນ ບົດຄວາມໜ້າ, ເຊິ່ງເປັນສະບັບຂະຫຍາຍຂອງວັດຖຸ ບົດຄວາມ, ຊະ​ນິດ​ຂອງ ບົດຄວາມເຕັມ. ໂດຍແລະຂະຫນາດໃຫຍ່, ການປະຕິບັດນີ້ບໍ່ໄດ້ປະຕິບັດສິ່ງທີ່ຂີ້ຮ້າຍຢູ່ໃນຕົວຂອງມັນເອງ - ມັນງ່າຍດາຍຫຼາຍ, ຄົນເຮົາອາດຈະເວົ້າວ່າ naive, ແຕ່ເຂົ້າໃຈທີ່ສຸດ. ຖ້າທ່ານຕັ້ງໂມດູນຄືນໃຫມ່ທຸກໆຄັ້ງທີ່ທ່ານປ່ຽນເສັ້ນທາງ, ຫຼັງຈາກນັ້ນທ່ານກໍ່ສາມາດຢູ່ກັບມັນໄດ້. ຢ່າງໃດກໍຕາມ, ການເຄື່ອນຍ້າຍລະຫວ່າງບົດຄວາມບົດຄວາມ, ສໍາລັບການຍົກຕົວຢ່າງ / feed → /all, ຮັບປະກັນທີ່ຈະຖິ້ມທຸກສິ່ງທຸກຢ່າງທີ່ກ່ຽວຂ້ອງກັບອາຫານສ່ວນບຸກຄົນ, ນັບຕັ້ງແຕ່ພວກເຮົາມີພຽງແຕ່ຫນຶ່ງ ລາຍຊື່ບົດຄວາມ, ທີ່ທ່ານຈໍາເປັນຕ້ອງໄດ້ໃສ່ຂໍ້ມູນໃຫມ່. ນີ້ອີກເທື່ອຫນຶ່ງເຮັດໃຫ້ພວກເຮົາຊ້ໍາກັນຂອງການຮ້ອງຂໍ.

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

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

ArticlesList: {
  ROUTE_FEED: [ 
    { Article1 },
    ...
  ],
  ROUTE_ALL: [ 
    { Article2 },
    ...
  ],
}

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

ArticlesIds: {
  ROUTE_FEED: [ '1', ... ],
  ROUTE_ALL: [ '1', '2', ... ],
},
ArticlesList: {
  '1': { Article1 }, 
  '2': { Article2 },
  ...
}

ລາຍຊື່ບົດຄວາມ ທີ່ນີ້ມັນເປັນພຽງແຕ່ປະເພດຂອງ repository ຂອງບົດຄວາມ. ບົດຄວາມທັງໝົດທີ່ຖືກດາວໂຫຼດໃນລະຫວ່າງຊ່ວງເວລາຂອງຜູ້ໃຊ້. ພວກເຮົາປິ່ນປົວພວກເຂົາດ້ວຍຄວາມລະມັດລະວັງທີ່ສຸດ, ເພາະວ່ານີ້ແມ່ນການຈະລາຈອນທີ່ອາດຈະໄດ້ຮັບການດາວໂຫຼດຜ່ານຄວາມເຈັບປວດບ່ອນໃດຫນຶ່ງໃນ metro ລະຫວ່າງສະຖານີ, ແລະພວກເຮົາແນ່ນອນບໍ່ຕ້ອງການທີ່ຈະເຮັດໃຫ້ເກີດຄວາມເຈັບປວດນີ້ກັບຜູ້ໃຊ້ອີກເທື່ອຫນຶ່ງໂດຍການບັງຄັບໃຫ້ລາວໂຫລດຂໍ້ມູນທີ່ລາວມີຢູ່ແລ້ວ. ດາວໂຫຼດແລ້ວ. ວັດຖຸ ArticlesIds ແມ່ນພຽງແຕ່ array ຂອງ IDs (ຄືກັບວ່າ "ເຊື່ອມຕໍ່") ກັບວັດຖຸ ບົດຄວາມ. ໂຄງສ້າງນີ້ຊ່ວຍໃຫ້ທ່ານສາມາດຫຼີກເວັ້ນການຊ້ໍາກັນຂໍ້ມູນທົ່ວໄປກັບເສັ້ນທາງແລະການນໍາໃຊ້ວັດຖຸຄືນໃຫມ່ ບົດຄວາມ ໃນ​ເວ​ລາ​ທີ່​ເຮັດ​ໃຫ້​ຫນ້າ​ຕອບ​ໂດຍ​ການ​ລວມ​ຂໍ້​ມູນ​ຂະ​ຫຍາຍ​ເຂົ້າ​ໄປ​ໃນ​ມັນ​.

ຜົນຜະລິດຂອງບັນຊີລາຍຊື່ຂອງບົດຄວາມໄດ້ກາຍເປັນຄວາມໂປ່ງໃສຫຼາຍ: ອົງປະກອບ iterator iterates ຜ່ານ array ທີ່ມີ ID ບົດຄວາມແລະແຕ້ມອົງປະກອບ teaser ບົດຄວາມ, ຜ່ານ Id ເປັນ prop, ແລະອົງປະກອບຂອງເດັກນ້ອຍ, ໃນທາງກັບກັນ, ດຶງຂໍ້ມູນທີ່ຈໍາເປັນຈາກ. ລາຍຊື່ບົດຄວາມ. ເມື່ອທ່ານໄປຫາຫນ້າສິ່ງພິມ, ພວກເຮົາໄດ້ຮັບວັນທີທີ່ມີຢູ່ແລ້ວຈາກ ລາຍຊື່ບົດຄວາມ, ພວກເຮົາເຮັດການຮ້ອງຂໍເພື່ອໃຫ້ໄດ້ຮັບຂໍ້ມູນທີ່ຂາດຫາຍໄປແລະພຽງແຕ່ເພີ່ມມັນໃສ່ວັດຖຸທີ່ມີຢູ່ແລ້ວ.

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

ເຮັດໃຫ້ການດາວໂຫຼດມີຄວາມມ່ວນຫຼາຍ

icing ໃນ cake refactoring ແມ່ນແນວຄວາມຄິດຂອງ skeletons, ເຊິ່ງເຮັດໃຫ້ຂະບວນການດາວໂຫຼດເນື້ອໃນໃນອິນເຕີເນັດຊ້າເປັນຫນ້າກຽດຊັງຫນ້ອຍລົງ. ບໍ່ມີການປຶກສາຫາລືກ່ຽວກັບເລື່ອງນີ້; ເສັ້ນທາງຈາກແນວຄວາມຄິດໄປສູ່ຕົວແບບຕົ້ນແບບໃຊ້ເວລາສອງຊົ່ວໂມງ. ການອອກແບບຕົວຈິງໄດ້ແຕ້ມຕົວມັນເອງ, ແລະພວກເຮົາໄດ້ສອນອົງປະກອບຂອງພວກເຮົາໃຫ້ສະແດງບລັອກ div ທີ່ງ່າຍດາຍ, ເກືອບບໍ່ສະເກັດເງິນໃນຂະນະທີ່ລໍຖ້າຂໍ້ມູນ. ໂດຍວິທີທາງການ, ວິທີການໂຫຼດນີ້ຊ່ວຍຫຼຸດຜ່ອນປະລິມານຮໍໂມນຄວາມກົດດັນໃນຮ່າງກາຍຂອງຜູ້ໃຊ້. ໂຄງກະດູກມີລັກສະນະດັ່ງນີ້:

ການໂຫຼດ

ສະທ້ອນໃຫ້ເຫັນ

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

ຫຼັງຈາກການປ່ອຍການປ່ຽນແປງທັງຫມົດເຫຼົ່ານີ້, ພວກເຮົາໄດ້ຮັບຄໍາຄິດເຫັນໃນທາງບວກ, ແລະມັນດີຫຼາຍ. ມັນເປັນແຮງບັນດານໃຈ. ຂອບ​ໃຈ! ຂຽນເພີ່ມເຕີມ.

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

ແຫຼ່ງຂໍ້ມູນ: www.habr.com