Habr front-end developer logs: refactoring සහ පරාවර්තනය

Habr අභ්‍යන්තරයෙන් ව්‍යුහගත වන්නේ කෙසේද, කාර්ය ප්‍රවාහය ව්‍යුහගත වන්නේ කෙසේද, සන්නිවේදනයන් ව්‍යුහගත වන්නේ කෙසේද, කුමන ප්‍රමිතීන් භාවිතා කරන්නේද සහ සාමාන්‍යයෙන් මෙහි කේතය ලියා ඇත්තේ කෙසේද යන්න පිළිබඳව මම සැමවිටම උනන්දු වෙමි. වාසනාවකට මෙන්, මට එවැනි අවස්ථාවක් ලැබුණි, මන්ද මම මෑතකදී හබ්රා කණ්ඩායමේ සාමාජිකයෙකු වූ බැවිනි. ජංගම අනුවාදයේ කුඩා ප්‍රතිනිර්මාණයක උදාහරණය භාවිතා කරමින්, මම ප්‍රශ්නයට පිළිතුරු දීමට උත්සාහ කරමි: මෙහි ඉදිරිපස වැඩ කිරීම කෙබඳුද යන්න. වැඩසටහනේ: Habr හි පුද්ගලික අත්දැකීම් පිළිබඳ සටහන් වලින් සෝස් සමඟ Node, Vue, Vuex සහ SSR.

සංවර්ධන කණ්ඩායම ගැන ඔබ දැනගත යුතු පළමු දෙය නම් අපෙන් ස්වල්ප දෙනෙක් සිටින බවයි. ප්රමාණවත් නොවේ - මේවා ඉදිරිපස තුනක්, පසුපස දෙකක් සහ සියලු Habr - Baxley හි තාක්ෂණික නායකත්වය. ඇත්ත වශයෙන්ම, පරීක්ෂකයෙක්, නිර්මාණකරුවෙකු, වඩීම් තුනක්, ආශ්චර්යමත් කොස්සක්, අලෙවිකරණ විශේෂඥයෙක් සහ අනෙකුත් බුඹුරුම් ද ඇත. නමුත් හබ්ර්ගේ මූලාශ්‍ර සඳහා සෘජු දායකයින් සිටින්නේ හය දෙනෙකු පමණි. මෙය තරමක් දුර්ලභ ය - පිටතින් යෝධ ව්‍යවසායයක් සේ පෙනෙන ඩොලර් මිලියන ගණනක ප්‍රේක්ෂක සංඛ්‍යාවක් සිටින ව්‍යාපෘතියක්, යථාර්ථයේ දී පෙනෙන්නේ හැකි තරම් පැතලි ආයතනික ව්‍යුහයක් සහිත සුවපහසු ආරම්භයක් ලෙස ය.

වෙනත් බොහෝ තොරතුරු තාක්ෂණ සමාගම් මෙන්, Habr කඩිසර අදහස්, CI භාවිතයන්, සහ එපමණයි. නමුත් මගේ හැඟීම් අනුව, නිෂ්පාදනයක් ලෙස හබ්ර් අඛණ්ඩව වඩා තරංගවල වර්ධනය වේ. එබැවින්, පේළියක ස්ප්‍රින්ට් කිහිපයක් සඳහා, අපි වෙහෙස මහන්සි වී යමක් කේත කිරීම, සැලසුම් කිරීම සහ ප්‍රතිනිර්මාණය කිරීම, යමක් කඩා එය සකස් කිරීම, ප්‍රවේශපත්‍ර නිරාකරණය කර නව ඒවා නිර්මාණය කිරීම, පෝරුවක් මත පා තබා අපගේ පාදවලට වෙඩි තබා ගැනීම, අවසානයේ විශේෂාංගය මුදා හැරීම සඳහා. නිෂ්පාදනය. එවිට යම් නිශ්ශබ්දතාවයක්, නැවත සංවර්ධනය කිරීමේ කාල පරිච්ඡේදයක්, “වැදගත්-හදිසි නොවන” චතුරස්රයේ ඇති දේ කිරීමට කාලය පැමිණේ.

එය හරියටම පහත සාකච්ඡා කරනු ලබන මෙම "ඕෆ්-සීසන්" ස්ප්රින්ට් වේ. මෙවර එයට Habr හි ජංගම පිටපත ප්‍රතිනිර්මාණය කිරීමක් ඇතුළත් විය. පොදුවේ ගත් කල, සමාගම ඒ සඳහා විශාල බලාපොරොත්තු තබා ඇති අතර, අනාගතයේ දී එය Habr ගේ අවතාරවල සම්පූර්ණ සත්වෝද්යානය ප්රතිස්ථාපනය කර විශ්වීය හරස් වේදිකා විසඳුමක් බවට පත් විය යුතුය. යම් දවසක අනුවර්තන පිරිසැලසුම, PWA, නොබැඳි මාදිලිය, පරිශීලක අභිරුචිකරණය සහ තවත් බොහෝ රසවත් දේවල් ඇත.

අපි කාර්යය සකස් කරමු

වරක්, සාමාන්‍ය නැගී සිටීමකදී, ඉදිරිපස එක් අයෙකු ජංගම අනුවාදයේ අදහස් සංරචකයේ ගෘහ නිර්මාණ ශිල්පයේ ගැටළු ගැන කතා කළේය. මෙය මනසේ තබාගෙන අපි කණ්ඩායම් මනෝචිකිත්සාවේ ආකෘතියෙන් ක්ෂුද්‍ර රැස්වීමක් සංවිධානය කළෙමු. හැමෝම මාරුවෙන් මාරුවට කිව්වා රිදෙන තැන්, හැම දෙයක්ම කොලේ සටහන් කළා, අනුකම්පා කළා, තේරුණා මිසක් කවුරුත් අත්පුඩි ගැහුවේ නෑ. එහි ප්‍රතිඵලය වූයේ ගැටලු 20ක ලැයිස්තුවක් වූ අතර, එයින් පැහැදිලි වූයේ ජංගම Habr හට තවමත් සාර්ථකත්වයට දිගු හා කටු සහිත මාවතක් තිබෙන බවයි.

මම මූලික වශයෙන් සැලකිලිමත් වූයේ සම්පත් භාවිතයේ කාර්යක්ෂමතාව සහ සුමට අතුරු මුහුණතක් ලෙස හඳුන්වන දේ ගැන ය. සෑම දිනකම, ගෙදර-වැඩ-ගෙදර යන මාර්ගයේ, මගේ පැරණි දුරකථනය සංග්‍රහයේ සිරස්තල 20ක් පෙන්වීමට මංමුලා සහගත ලෙස උත්සාහ කරන බව මම දුටුවෙමි. එය මේ වගේ දෙයක් පෙනුණා:

නැවත සකස් කිරීමට පෙර ජංගම Habr අතුරුමුහුණත

මොකද මෙතන වෙන්නෙ? කෙටියෙන් කිවහොත්, පරිශීලකයා ලොග් වී සිටියත් නැතත්, සේවාදායකයා HTML පිටුව සෑම කෙනෙකුටම එකම ආකාරයකින් ලබා දුන්නේය. එවිට සේවාලාභියා JS පූරණය වී නැවත අවශ්‍ය දත්ත ඉල්ලයි, නමුත් අවසරය සඳහා සකස් කර ඇත. එනම්, අපි ඇත්ත වශයෙන්ම එකම කාර්යය දෙවරක් කළෙමු. අතුරු මුහුණත දිලිසෙන අතර, පරිශීලකයා හොඳ අමතර කිලෝබයිට් සියයක් බාගත කර ඇත. විස්තරාත්මකව සෑම දෙයක්ම වඩාත් බියජනක ලෙස පෙනුනි.

පැරණි SSR-CSR යෝජනා ක්රමය. Node JS HTML ජනනය කිරීමේදී කාර්යබහුල නොවන විට සහ API වෙත ඉල්ලීම් ප්‍රොක්සි කළ හැකි විට C3 සහ C4 අදියරවලදී පමණක් අවසරය ලබා ගත හැක.

එකල අපගේ ගෘහනිර්මාණ ශිල්පය ඉතා නිවැරදිව විස්තර කරන ලද්දේ Habr භාවිතා කරන්නෙකු විසිනි:

ජංගම අනුවාදය ජරාවක්. මම ඒක ඒ විදියටම කියනවා. SSR සහ CSR වල භයානක සංයෝජනයක්.

කොච්චර දුකක් ආවත් අපිට ඒක පිළිගන්න සිද්ධ වුණා.

මම විකල්ප තක්සේරු කර, "එය නරකයි, එය නිවැරදිව කරන්න" මට්ටමේ විස්තරයක් සහිත ජිරා හි ටිකට් පතක් නිර්මාණය කර පුළුල් පහරවල් වලින් කාර්යය දිරාපත් කළෙමි:

• දත්ත නැවත භාවිතා කිරීම,
• නැවත ඇඳීම් ගණන අවම කිරීම,
• අනුපිටපත් ඉල්ලීම් ඉවත් කරන්න,
• පැටවීමේ ක්‍රියාවලිය වඩාත් පැහැදිලි කරන්න.

අපි දත්ත නැවත භාවිතා කරමු

න්‍යායාත්මකව, සේවාදායක පැත්තේ විදැහුම්කරණය සැලසුම් කර ඇත්තේ ගැටළු දෙකක් විසඳීම සඳහා ය: සෙවුම් යන්ත්‍ර සීමාවන්ගෙන් පීඩා විඳීමට නොවේ SPA සුචිගත කිරීම සහ මෙට්රික් වැඩි දියුණු කරන්න FMP (නොවැළැක්විය හැකි ලෙස නරක අතට හැරේ ටීටීඅයි) සම්භාව්‍ය දර්ශනයක එය අවසානයේ 2013 දී Airbnb හි සකස් කරන ලදී වසර (තවමත් Backbone.js මත), SSR යනු Node පරිසරය තුළ ක්‍රියාත්මක වන සමස්ථානික JS යෙදුමයි. සේවාදායකය විසින් ඉල්ලීමට ප්‍රතිචාරයක් ලෙස ජනනය කරන ලද පිරිසැලසුම යවයි. එවිට සේවාලාභියාගේ පැත්තෙන් නැවත සජලනය සිදු වේ, පසුව පිටු නැවත පූරණය නොකර සෑම දෙයක්ම ක්රියා කරයි. Habr සඳහා, පෙළ අන්තර්ගතය සහිත වෙනත් බොහෝ සම්පත් සඳහා, සෙවුම් යන්ත්‍ර සමඟ මිත්‍ර සබඳතා ගොඩනඟා ගැනීමේදී සේවාදායක විදැහුම්කරණය තීරණාත්මක අංගයකි.

තාක්‍ෂණයේ පැමිණීමෙන් වසර හයකට වැඩි කාලයක් ගතවී ඇතත්, මේ කාලය තුළ ඉදිරිපස ලෝකයේ පාලම යටට ජලය විශාල ප්‍රමාණයක් ගලා ගොස් ඇතත්, බොහෝ සංවර්ධකයින් සඳහා මෙම අදහස තවමත් රහසිගතව සැඟවී ඇත. අපි පැත්තකට නොගොස් නිෂ්පාදනය සඳහා SSR සහාය ඇතිව Vue යෙදුමක් ඉදිරිපත් කළෙමු, එක් කුඩා විස්තරයක් මග හැරී ඇත: අපි ආරම්භක තත්වය සේවාලාභියා වෙත යැවුවේ නැත.

ඇයි? මෙම ප්රශ්නයට නිශ්චිත පිළිතුරක් නොමැත. එක්කෝ ඔවුන්ට සේවාදායකයෙන් ලැබෙන ප්‍රතිචාරයේ ප්‍රමාණය වැඩි කිරීමට අවශ්‍ය නොවීය, නැතහොත් වෙනත් වාස්තු විද්‍යාත්මක ගැටලු රාශියක් නිසා හෝ එය සරලව ඉවත් නොවීය. එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින්, තත්වය ඉවතට විසි කිරීම සහ සේවාදායකයා කළ සෑම දෙයක්ම නැවත භාවිතා කිරීම ඉතා සුදුසු සහ ප්‍රයෝජනවත් බව පෙනේ. කාර්යය ඇත්ත වශයෙන්ම සුළුපටු ය - රාජ්යය සරලව එන්නත් කරනු ලැබේ ක්‍රියාත්මක කිරීමේ සන්දර්භය තුළට, සහ Vue එය ගෝලීය විචල්‍යයක් ලෙස ජනනය කරන ලද පිරිසැලසුම වෙත ස්වයංක්‍රීයව එක් කරයි: window.__INITIAL_STATE__.

පැන නැගී ඇති එක් ගැටළුවක් නම් චක්‍රීය ව්‍යුහයන් JSON බවට පරිවර්තනය කිරීමට නොහැකි වීමයි.චක්රලේඛය යොමු කිරීම); එවැනි ව්යුහයන් ඔවුන්ගේ පැතලි සගයන් සමඟ සරලව ප්රතිස්ථාපනය කිරීමෙන් විසඳා ඇත.

මීට අමතරව, UGC අන්තර්ගතය සමඟ කටයුතු කරන විට, HTML බිඳ නොදැමීම සඳහා දත්ත HTML ආයතන බවට පරිවර්තනය කළ යුතු බව ඔබ මතක තබා ගත යුතුය. මෙම අරමුණු සඳහා අපි භාවිතා කරමු he.

නැවත ඇඳීම් අවම කිරීම

ඉහත රූප සටහනෙන් ඔබට පෙනෙන පරිදි, අපගේ නඩුවේදී, එක් Node JS අවස්ථාවක් කාර්යයන් දෙකක් ඉටු කරයි: SSR සහ API හි "ප්‍රොක්සි", පරිශීලක අවසරය සිදු වේ. නෝඩය තනි නූල් සහ SSR ශ්‍රිතය සමමුහුර්ත වන බැවින් මෙම තත්වය සේවාදායකයේ JS කේතය ක්‍රියාත්මක වන විට අවසර දීමට නොහැකි වේ. එනම්, Callstack යමක් සමඟ කාර්යබහුල වන විට සේවාදායකයාට ඉල්ලීම් යැවිය නොහැක. පරිශීලක සැසිය සැලකිල්ලට ගනිමින් සේවාදායකයාගේ දත්ත යාවත්කාලීන කළ යුතු බැවින් අපි තත්වය යාවත්කාලීන කළ නමුත් අතුරු මුහුණත ඇඹරීම නතර කළේ නැත. පරිශීලකයාගේ පිවිසුම සැලකිල්ලට ගනිමින් නිවැරදි දත්ත ආරම්භක තත්වයට පත් කිරීමට අපට අපගේ යෙදුම ඉගැන්වීමට අවශ්‍ය විය.

ගැටලුවට විසඳුම් දෙකක් පමණක් තිබුණි:

• හරස්-සේවාදායක ඉල්ලීම් සඳහා අවසර දත්ත අමුණන්න;
• Node JS ස්ථර වෙනම අවස්ථා දෙකකට බෙදන්න.

පළමු විසඳුම සඳහා සේවාදායකයේ ගෝලීය විචල්‍යයන් භාවිතා කිරීම අවශ්‍ය වූ අතර දෙවැන්න අවම වශයෙන් මාසයකින් කාර්යය සම්පූර්ණ කිරීමේ කාල සීමාව දීර්ඝ කළේය.

තේරීමක් කරන්නේ කෙසේද? Habr බොහෝ විට අවම ප්රතිරෝධයේ මාර්ගය ඔස්සේ ගමන් කරයි. අවිධිමත් ලෙස, අදහස සිට මූලාකෘතිය දක්වා චක්රය අවම වශයෙන් අඩු කිරීමට සාමාන්ය ආශාවක් පවතී. නිෂ්පාදිතය පිළිබඳ ආකල්පයේ ආකෘතිය booking.com හි උපකල්පන තරමක් සිහිපත් කරයි, එකම වෙනස වන්නේ Habr පරිශීලක ප්‍රතිපෝෂණය වඩාත් බැරෑරුම් ලෙස සලකන අතර සංවර්ධකයෙකු ලෙස එවැනි තීරණ ගැනීමට ඔබව විශ්වාස කිරීමයි.

මෙම තර්කනය සහ ගැටලුව ඉක්මනින් විසඳීමට මගේම ආශාව අනුගමනය කරමින්, මම ගෝලීය විචල්යයන් තෝරා ගත්තෙමි. තවද, බොහෝ විට සිදු වන පරිදි, ඔබ ඉක්මනින් හෝ පසුව ඔවුන් සඳහා ගෙවිය යුතුය. අපි වහාම පාහේ ගෙවා ඇත: අපි සති අන්තයේ වැඩ කළා, ප්රතිවිපාක ඉවත් කළා, ලිවීය පශ්චාත් මරණ පරීක්ෂණය සහ සේවාදායකය කොටස් දෙකකට බෙදීමට පටන් ගත්තේය. දෝෂය ඉතා මෝඩ වූ අතර, එය ඇතුළත් දෝෂය ප්‍රතිනිෂ්පාදනය කිරීම පහසු නොවීය. ඔව්, මේ සඳහා ලැජ්ජාවකි, නමුත් එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින්, පැකිලී හා කෙඳිරිගාමින්, ගෝලීය විචල්‍යයන් සහිත මගේ PoC කෙසේ වෙතත් නිෂ්පාදනයට ගොස් නව “තුඩු දෙකේ” ගෘහ නිර්මාණ ශිල්පයකට මාරු වන තෙක් බලා සිටින අතරතුර ඉතා සාර්ථකව ක්‍රියා කරයි. මෙය වැදගත් පියවරක් විය, මන්ද විධිමත් ලෙස ඉලක්කය සපුරා ගත් බැවිනි - SSR සම්පූර්ණයෙන්ම භාවිතයට සූදානම් පිටුවක් ලබා දීමට ඉගෙන ගත් අතර UI වඩාත් සන්සුන් විය.

නැවත සකස් කිරීමේ පළමු අදියරෙන් පසු ජංගම Habr අතුරුමුහුණත

අවසාන වශයෙන්, ජංගම අනුවාදයේ SSR-CSR ගෘහ නිර්මාණ ශිල්පය මෙම පින්තූරයට යොමු කරයි:

"ද්වි-නෝඩ්" SSR-CSR පරිපථය. Node JS API සෑම විටම අසමමුහුර්ත I/O සඳහා සුදානම් වන අතර SSR ශ්‍රිතය මඟින් අවහිර නොකෙරේ, දෙවැන්න වෙනම අවස්ථාවක පිහිටා ඇත. Query chain #3 අවශ්‍ය නොවේ.

අනුපිටපත් ඉල්ලීම් ඉවත් කිරීම

උපාමාරු සිදු කිරීමෙන් පසුව, පිටුවේ මුල් විදැහුම්කරණය තවදුරටත් අපස්මාරය අවුලුවා නැත. නමුත් SPA මාදිලියේ Habr තවදුරටත් භාවිතා කිරීම තවමත් ව්‍යාකූලත්වයට හේතු විය.

පරිශීලක ප්‍රවාහයේ පදනම පෝරමයේ සංක්‍රාන්ති බැවින් ලිපි ලැයිස්තුව → ලිපිය → අදහස් සහ අනෙක් අතට, මෙම දාමයේ සම්පත් පරිභෝජනය මුලින්ම ප්‍රශස්ත කිරීම වැදගත් විය.

පසු සංග්‍රහයට නැවත පැමිණීම නව දත්ත ඉල්ලීමක් ඇති කරයි

ගැඹුරට හෑරීමට අවශ්‍ය නොවීය. ඉහත තිර විකාශනය තුළ, යෙදුම ආපසු ස්වයිප් කිරීමේදී ලිපි ලැයිස්තුව නැවත ඉල්ලන බව ඔබට දැක ගත හැකි අතර, ඉල්ලීම අතරතුර අපට ලිපි නොපෙනේ, එනම් පෙර දත්ත කොහේ හෝ අතුරුදහන් වන බවයි. ලිපි ලැයිස්තු සංරචකය ප්‍රාදේශීය රාජ්‍යයක් භාවිතා කරන අතර විනාශ කිරීමේදී එය නැති වන බව පෙනේ. ඇත්ත වශයෙන්ම, යෙදුම ගෝලීය රාජ්‍යයක් භාවිතා කර ඇත, නමුත් Vuex ගෘහ නිර්මාණ ශිල්පය ප්‍රධාන වශයෙන් ගොඩනගා ඇත: මොඩියුල පිටු වලට බැඳී ඇති අතර ඒවා මාර්ගවලට බැඳී ඇත. එපමණක් නොව, සියලුම මොඩියුල "ඉවත දැමිය හැකි" වේ - පිටුවට එක් එක් පසු සංචාරය සම්පූර්ණ මොඩියුලය නැවත ලිවීය:

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

සමස්තයක් වශයෙන්, අපට මොඩියුලයක් තිබුණි ලිපි ලැයිස්තුව, වර්ගයේ වස්තූන් අඩංගු වේ ලිපිය සහ මොඩියුලය පිටු ලිපිය, වස්තුවේ විස්තීර්ණ අනුවාදයක් විය ලිපිය, වර්ගයක ලිපිය සම්පූර්ණ. විශාල වශයෙන්, මෙම ක්‍රියාත්මක කිරීම තමා තුළම භයානක කිසිවක් ගෙන යන්නේ නැත - එය ඉතා සරල ය, කෙනෙකුට බොළඳ යැයි පැවසිය හැකිය, නමුත් අතිශයින්ම තේරුම් ගත හැකිය. ඔබ මාර්ගය වෙනස් කරන සෑම අවස්ථාවකම ඔබ මොඩියුලය නැවත සකසන්නේ නම්, ඔබට එය සමඟ ජීවත් විය හැකිය. කෙසේ වෙතත්, උදාහරණයක් ලෙස ලිපි සංග්‍රහ අතර ගමන් කිරීම /පෝෂණය → /සියල්ල, අපට ඇත්තේ එකක් පමණක් බැවින් පුද්ගලික සංග්‍රහයට අදාළ සියල්ල ඉවත දැමීමට සහතික වේ ලිපි ලැයිස්තුව, ඔබ නව දත්ත දැමිය යුතු බවට. මෙය නැවතත් ඉල්ලීම් අනුපිටපත් කිරීමට අපව යොමු කරයි.

මාතෘකාව හාරා ගැනීමට මට හැකි වූ සෑම දෙයක්ම එකතු කර, මම නව රාජ්ය ව්යුහයක් සකස් කර එය මගේ සගයන් වෙත ඉදිරිපත් කළෙමි. සාකච්ඡා දිගු වූ නමුත් අවසානයේ පක්ෂව තර්ක සැකයන් අභිබවා ගිය අතර මම ක්‍රියාත්මක කිරීමට පටන් ගතිමි.

විසඳුමක තර්කනය පියවර දෙකකින් වඩාත් හොඳින් හෙළිදරව් වේ. මුලින්ම අපි Vuex මොඩියුලය පිටු වලින් විසංයෝජනය කර මාර්ග වෙත කෙලින්ම සම්බන්ධ කිරීමට උත්සාහ කරමු. ඔව්, ගබඩාවේ තව ටිකක් දත්ත ඇත, ලබා ගන්නන් ටිකක් සංකීර්ණ වනු ඇත, නමුත් අපි දෙවරක් ලිපි පූරණය නොකරමු. ජංගම අනුවාදය සඳහා, මෙය සමහර විට ශක්තිමත්ම තර්කය වේ. එය මේ වගේ දෙයක් පෙනෙනු ඇත:

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

නමුත් ලිපි ලැයිස්තු බහු මාර්ග අතර අතිච්ඡාදනය විය හැකි නම් සහ අපට වස්තු දත්ත නැවත භාවිතා කිරීමට අවශ්‍ය නම් කුමක් කළ යුතුද? ලිපිය තැපැල් පිටුව විදැහුම් කිරීමට, එය බවට පත් කිරීම ලිපිය සම්පූර්ණ? මෙම අවස්ථාවේදී, එවැනි ව්යුහයක් භාවිතා කිරීම වඩාත් තාර්කික වනු ඇත:

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

ලිපි ලැයිස්තුව මෙන්න එය එක්තරා ආකාරයක ලිපි ගබඩාවක් පමණි. පරිශීලක සැසිය තුළ බාගත කළ සියලුම ලිපි. අපි ඔවුන්ට උපරිම සැලකිල්ලෙන් සලකන්නෙමු, මන්ද මෙය දුම්රිය ස්ථාන අතර මෙට්‍රෝවේ කොතැනක හෝ වේදනාවක් හරහා බාගත කර ඇති ගමනාගමනය වන අතර, පරිශීලකයාට දැනටමත් ඇති දත්ත පූරණය කිරීමට බල කිරීමෙන් ඔහුට මෙම වේදනාව නැවත ඇති කිරීමට අපට අවශ්‍ය නැත. බාගත කර ඇත. වස්තුවකි ලිපිIds හුදෙක් වස්තු සඳහා හැඳුනුම්පත් මාලාවක් ("සබැඳි" ලෙස) වේ ලිපිය. මෙම ව්‍යුහය මඟින් මාර්ග වලට පොදු දත්ත අනුපිටපත් කිරීම සහ වස්තුව නැවත භාවිතා කිරීම වළක්වා ගැනීමට ඔබට ඉඩ සලසයි ලිපිය තැපැල් පිටුවක් විදැහුම් කරන විට එයට දිගු දත්ත ඒකාබද්ධ කිරීමෙන්.

ලිපි ලැයිස්තුවේ ප්‍රතිදානය ද වඩාත් පාරදෘශ්‍ය වී ඇත: පුනරාවර්තක සංරචකය ලිපි හැඳුනුම්පත් සමඟ අරාව හරහා පුනරාවර්තනය වී ලිපි ටීසර් සංරචකය අඳිමින්, හැඳුනුම්පත මුක්කුවක් ලෙස පසුකර, සහ ළමා සංරචකය, අවශ්‍ය දත්ත ලබා ගනී. ලිපි ලැයිස්තුව. ඔබ ප්‍රකාශන පිටුවට යන විට, අපි දැනටමත් පවතින දිනය ලබා ගනිමු ලිපි ලැයිස්තුව, අතුරුදහන් වූ දත්ත ලබා ගැනීමට සහ පවතින වස්තුවට සරලව එකතු කිරීමට අපි ඉල්ලීමක් කරමු.

මෙම ප්රවේශය වඩා හොඳ වන්නේ ඇයි? මා ඉහත ලියා ඇති පරිදි, බාගත කළ දත්ත සම්බන්ධයෙන් මෙම ප්රවේශය වඩාත් මෘදු වන අතර එය නැවත භාවිතා කිරීමට ඔබට ඉඩ සලසයි. නමුත් මෙයට අමතරව, එය එවැනි ගෘහ නිර්මාණ ශිල්පයකට හොඳින් ගැලපෙන නව හැකියාවන් සඳහා මාර්ගය විවෘත කරයි. උදාහරණයක් ලෙස, ඡන්ද විමසීම සහ ලිපි පෙනෙන පරිදි සංග්‍රහයට පැටවීම. අපට සරලවම නවතම පළ කිරීම් "ගබඩාව" තුළ තැබිය හැකිය ලිපි ලැයිස්තුව, නව හැඳුනුම්පත් වල වෙනම ලැයිස්තුවක් සුරකින්න ලිපිIds සහ ඒ ගැන පරිශීලකයාට දැනුම් දෙන්න. අපි "නව ප්‍රකාශන පෙන්වන්න" බොත්තම මත ක්ලික් කළ විට, අපි දැනට පවතින ලිපි ලැයිස්තුවේ අරාවේ ආරම්භයට නව හැඳුනුම්පත් ඇතුළත් කරන අතර සෑම දෙයක්ම පාහේ ඉන්ද්‍රජාලිකව ක්‍රියා කරයි.

බාගත කිරීම වඩාත් විනෝදජනක කිරීම

ප්‍රතිනිර්මාණය කිරීමේ කේක් මත අයිසිං යනු ඇටසැකිලි සංකල්පය වන අතර එමඟින් මන්දගාමී අන්තර්ජාලයේ අන්තර්ගතය බාගත කිරීමේ ක්‍රියාවලිය තරමක් පිළිකුල් සහගත වේ. මෙම කාරණය සම්බන්ධයෙන් කිසිදු සාකච්ඡාවක් නොතිබුණි; අදහසේ සිට මූලාකෘතිය දක්වා මාර්ගය වචනාර්ථයෙන් පැය දෙකක් ගත විය. සැලසුම ප්‍රායෝගිකව ඇද ගන්නා ලද අතර, දත්ත සඳහා රැඳී සිටින අතරතුර සරල, යන්තම් දිලිසෙන div blocks ලබා දීමට අපි අපගේ සංරචක වලට උගන්වමු. විෂයානුබද්ධව, පැටවීම සඳහා මෙම ප්රවේශය ඇත්ත වශයෙන්ම පරිශීලකයාගේ ශරීරයේ ආතති හෝමෝන ප්රමාණය අඩු කරයි. ඇටසැකිල්ල මේ වගේ ය:

Habraloading

පිළිබිඹු කරයි

මම හබ්රේ හි මාස හයක් වැඩ කර ඇති අතර මගේ මිතුරන් තවමත් අසයි: හොඳයි, ඔබ එයට කැමති වන්නේ කෙසේද? හොඳයි, සුවපහසුයි - ඔව්. නමුත් මෙම කාර්යය අනෙක් ඒවාට වඩා වෙනස් වන දෙයක් තිබේ. මම ඔවුන්ගේ නිෂ්පාදනයට සම්පූර්ණයෙන්ම උදාසීන වූ කණ්ඩායම්වල වැඩ කළෙමි, ඔවුන්ගේ පරිශීලකයින් කවුදැයි නොදැන හෝ තේරුම් නොගත්තෙමි. නමුත් මෙහි සෑම දෙයක්ම වෙනස් ය. මෙහිදී ඔබ කරන දෙයට ඔබ වගකිව යුතු යැයි හැඟේ. විශේෂාංගයක් සංවර්ධනය කිරීමේ ක්‍රියාවලියේදී, ඔබ අර්ධ වශයෙන් එහි හිමිකරු බවට පත් වේ, ඔබේ ක්‍රියාකාරිත්වයට අදාළ සියලුම නිෂ්පාදන රැස්වීම්වලට සහභාගී වන්න, යෝජනා ඉදිරිපත් කරන්න සහ තීරණ ඔබම ගන්න. ඔබ සෑම දිනකම භාවිතා කරන නිෂ්පාදනයක් ඔබ විසින්ම සාදා ගැනීම ඉතා සිසිල් ය, නමුත් ඔබට වඩා හොඳ පුද්ගලයින් සඳහා කේතය ලිවීම ඇදහිය නොහැකි හැඟීමක් පමණි (උපහාසයක් නැත).

මෙම සියලු වෙනස්කම් මුදා හැරීමෙන් පසුව, අපට ධනාත්මක ප්‍රතිපෝෂණ ලැබුණි, එය ඉතා හොඳ විය. එය ආශ්වාදජනකයි. ඔයාට ස්තූතියි! තව ලියන්න.

ගෝලීය විචල්‍යයන්ගෙන් පසුව අපි ගෘහ නිර්මාණ ශිල්පය වෙනස් කිරීමට සහ ප්‍රොක්සි ස්ථරය වෙනම අවස්ථාවක් බවට පත් කිරීමට තීරණය කළ බව මම ඔබට මතක් කරමි. "ද්වි-නෝඩ්" ගෘහ නිර්මාණ ශිල්පය දැනටමත් පොදු බීටා පරීක්ෂණ ආකාරයෙන් නිකුත් කර ඇත. දැන් ඕනෑම කෙනෙකුට එයට මාරු වී ජංගම Habr වඩා හොඳ කිරීමට අපට උදවු කළ හැක. අදට එච්චරයි. අදහස් දැක්වීමේදී ඔබගේ සියලු ප්‍රශ්නවලට පිළිතුරු දීමට මම සතුටු වෙමි.

මූලාශ්රය: www.habr.com