Habr ફ્રન્ટ-એન્ડ ડેવલપર લોગ્સ: રિફેક્ટરિંગ અને રિફ્લેક્ટિંગ

મને હંમેશા રસ છે કે Habr ની અંદરથી કેવી રીતે રચના કરવામાં આવે છે, વર્કફ્લો કેવી રીતે સંરચિત થાય છે, સંચાર કેવી રીતે સંરચિત થાય છે, કયા ધોરણોનો ઉપયોગ કરવામાં આવે છે અને સામાન્ય રીતે અહીં કોડ કેવી રીતે લખવામાં આવે છે. સદનસીબે, મને આવી તક મળી, કારણ કે હું તાજેતરમાં જ હબરા ટીમનો ભાગ બન્યો છું. મોબાઇલ સંસ્કરણના નાના રિફેક્ટરિંગના ઉદાહરણનો ઉપયોગ કરીને, હું પ્રશ્નનો જવાબ આપવાનો પ્રયાસ કરીશ: અહીં આગળના ભાગમાં કામ કરવાનું શું છે. પ્રોગ્રામમાં: નોડ, વ્યુ, વ્યુએક્સ અને એસએસઆર હબરમાં વ્યક્તિગત અનુભવ વિશે નોંધોમાંથી ચટણી સાથે.

તમારે ડેવલપમેન્ટ ટીમ વિશે જાણવાની પ્રથમ વસ્તુ એ છે કે આપણામાંથી થોડા છે. પૂરતું નથી - આ ત્રણ મોરચા, બે પીઠ અને તમામ હેબ્રની તકનીકી લીડ છે - બેક્સલી. અલબત્ત, એક પરીક્ષક, એક ડિઝાઇનર, ત્રણ વાદિમ, એક ચમત્કાર સાવરણી, એક માર્કેટિંગ નિષ્ણાત અને અન્ય બમ્બુરમ્સ પણ છે. પરંતુ હેબ્રના સ્ત્રોતોમાં ફક્ત છ સીધા ફાળો આપનારા છે. આ એકદમ દુર્લભ છે - કરોડો-ડોલરના પ્રેક્ષકો સાથેનો પ્રોજેક્ટ, જે બહારથી એક વિશાળ એન્ટરપ્રાઇઝ જેવો દેખાય છે, વાસ્તવમાં શક્ય સપાટ સંસ્થાકીય માળખા સાથે હૂંફાળું સ્ટાર્ટઅપ જેવો દેખાય છે.

અન્ય ઘણી IT કંપનીઓની જેમ, Habr એ ચપળ વિચારો, CI પ્રેક્ટિસનો વ્યવસાય કરે છે અને બસ આટલું જ. પરંતુ મારી લાગણીઓ અનુસાર, ઉત્પાદન તરીકે હેબર સતત કરતાં મોજામાં વધુ વિકાસ કરી રહ્યું છે. તેથી, સળંગ અનેક સ્પ્રિન્ટ્સ માટે, અમે ખંતપૂર્વક કંઈક કોડ કરીએ છીએ, ડિઝાઇન કરીએ છીએ અને ફરીથી ડિઝાઇન કરીએ છીએ, કંઈક તોડીએ છીએ અને તેને ઠીક કરીએ છીએ, ટિકિટો ઉકેલીએ છીએ અને નવી બનાવીએ છીએ, રેક પર પગ મુકીએ છીએ અને પગમાં ગોળી મારીએ છીએ, જેથી આખરે આ સુવિધાને બહાર પાડી શકાય. ઉત્પાદન અને પછી ત્યાં એક ચોક્કસ આરામ, પુનર્વિકાસનો સમયગાળો, "મહત્વપૂર્ણ-તાકીદ નથી" ચતુર્થાંશમાં શું છે તે કરવાનો સમય આવે છે.

તે ચોક્કસપણે આ "ઓફ-સીઝન" સ્પ્રિન્ટ છે જેની નીચે ચર્ચા કરવામાં આવશે. આ વખતે તેમાં Habr ના મોબાઇલ સંસ્કરણનું રિફેક્ટિંગ શામેલ છે. સામાન્ય રીતે, કંપનીને તેના માટે ઘણી આશાઓ છે, અને ભવિષ્યમાં તેણે હેબ્રના અવતારોના સમગ્ર પ્રાણી સંગ્રહાલયને બદલવું જોઈએ અને સાર્વત્રિક ક્રોસ-પ્લેટફોર્મ સોલ્યુશન બનવું જોઈએ. કોઈ દિવસ અનુકૂલનશીલ લેઆઉટ, PWA, ઑફલાઇન મોડ, વપરાશકર્તા કસ્ટમાઇઝેશન અને અન્ય ઘણી રસપ્રદ વસ્તુઓ હશે.

ચાલો કાર્ય સેટ કરીએ

એકવાર, એક સામાન્ય સ્ટેન્ડ-અપ પર, આગળનામાંથી એકે મોબાઇલ સંસ્કરણના ટિપ્પણી ઘટકના આર્કિટેક્ચરમાં સમસ્યાઓ વિશે વાત કરી. આને ધ્યાનમાં રાખીને, અમે ગ્રુપ સાયકોથેરાપીના ફોર્મેટમાં માઇક્રો-મીટિંગનું આયોજન કર્યું. દરેક વ્યક્તિએ વારાફરતી કહ્યું કે ક્યાં દુઃખ થયું, તેઓએ કાગળ પર બધું રેકોર્ડ કર્યું, તેઓ સહાનુભૂતિ દર્શાવતા હતા, તેઓ સમજી ગયા હતા, સિવાય કે કોઈએ તાળી પાડી ન હતી. પરિણામ એ 20 સમસ્યાઓની સૂચિ હતી, જેણે સ્પષ્ટ કર્યું હતું કે મોબાઇલ હેબર પાસે હજી સફળતાનો લાંબો અને કાંટાળો માર્ગ છે.

હું મુખ્યત્વે સંસાધનના ઉપયોગની કાર્યક્ષમતા અને સરળ ઈન્ટરફેસ કોને કહેવાય તે અંગે ચિંતિત હતો. દરરોજ, હોમ-વર્ક-હોમ રૂટ પર, મેં મારા જૂના ફોનને ફીડમાં 20 હેડલાઇન્સ પ્રદર્શિત કરવાનો સખત પ્રયાસ કરતા જોયો. તે કંઈક આના જેવું દેખાતું હતું:

રિફેક્ટરિંગ પહેલાં મોબાઇલ Habr ઇન્ટરફેસ

અહિયાં શું થઇ રહ્યું છે? ટૂંકમાં, સર્વર દરેકને એ જ રીતે HTML પૃષ્ઠ પ્રદાન કરે છે, પછી ભલે વપરાશકર્તા લૉગ ઇન થયો હોય કે ન હોય. પછી ક્લાયંટ JS લોડ થાય છે અને ફરીથી જરૂરી ડેટાની વિનંતી કરે છે, પરંતુ અધિકૃતતા માટે એડજસ્ટ કરવામાં આવે છે. એટલે કે, અમે ખરેખર એક જ કામ બે વાર કર્યું. ઈન્ટરફેસ ફ્લિકર થયો, અને વપરાશકર્તાએ સારા સો વધારાના કિલોબાઈટ ડાઉનલોડ કર્યા. વિગતવાર બધું વધુ વિલક્ષણ દેખાતું હતું.

જૂની SSR-CSR યોજના. અધિકૃતતા ફક્ત C3 અને C4 તબક્કામાં જ શક્ય છે, જ્યારે નોડ JS HTML જનરેટ કરવામાં વ્યસ્ત ન હોય અને API ને પ્રોક્સી વિનંતીઓ કરી શકે.

તે સમયના અમારા આર્કિટેક્ચરને હેબર વપરાશકર્તાઓમાંથી એક દ્વારા ખૂબ જ સચોટ રીતે વર્ણવવામાં આવ્યું હતું:

મોબાઇલ સંસ્કરણ વાહિયાત છે. હું તેને જેમ છે તેમ કહી રહ્યો છું. SSR અને CSR નું ભયંકર સંયોજન.

ભલે તે ગમે તેટલું દુઃખી હોય, અમારે તે સ્વીકારવું પડ્યું.

મેં વિકલ્પોનું મૂલ્યાંકન કર્યું, "તે હવે ખરાબ છે, તે બરાબર કરો" ના સ્તરે વર્ણન સાથે જીરામાં ટિકિટ બનાવી અને કાર્યને વ્યાપક સ્ટ્રોકમાં વિઘટિત કર્યું:

• ડેટાનો પુનઃઉપયોગ,
• ફરીથી દોરવાની સંખ્યા ઘટાડવી,
• ડુપ્લિકેટ વિનંતીઓ દૂર કરો,
• લોડિંગ પ્રક્રિયાને વધુ સ્પષ્ટ બનાવો.

ચાલો ડેટાનો ફરીથી ઉપયોગ કરીએ

સૈદ્ધાંતિક રીતે, સર્વર-સાઇડ રેન્ડરિંગ બે સમસ્યાઓ ઉકેલવા માટે રચાયેલ છે: સર્ચ એન્જિન મર્યાદાઓથી પીડાય નહીં એસપીએ અનુક્રમણિકા અને મેટ્રિકમાં સુધારો કરો FMP (અનિવાર્યપણે બગડવું ટ્ટી). ક્લાસિક દૃશ્યમાં કે આખરે એરબીએનબીમાં 2013 માં ઘડવામાં આવ્યું હતું વર્ષ (હજુ પણ Backbone.js પર), SSR એ નોડ પર્યાવરણમાં ચાલતી સમાન આઇસોમોર્ફિક JS એપ્લિકેશન છે. સર્વર વિનંતીના પ્રતિભાવ તરીકે જનરેટ કરેલ લેઆઉટને ખાલી મોકલે છે. પછી ક્લાયંટ બાજુ પર રીહાઇડ્રેશન થાય છે, અને પછી બધું પૃષ્ઠ ફરીથી લોડ કર્યા વિના કાર્ય કરે છે. Habr માટે, ટેક્સ્ટ કન્ટેન્ટ સાથેના અન્ય ઘણા સંસાધનો માટે, સર્વર રેન્ડરિંગ એ સર્ચ એન્જિન સાથે મૈત્રીપૂર્ણ સંબંધો બનાવવા માટે એક મહત્વપૂર્ણ તત્વ છે.

ટેક્નોલોજીના આગમનને છ વર્ષથી વધુ સમય વીતી ગયો હોવા છતાં, અને આ સમય દરમિયાન ફ્રન્ટ-એન્ડ વિશ્વમાં પુલની નીચે ઘણું પાણી વહી ગયું છે, ઘણા વિકાસકર્તાઓ માટે આ વિચાર હજુ પણ ગુપ્તતામાં છવાયેલો છે. અમે એક બાજુએ ઊભા ન રહીને ઉત્પાદન માટે SSR સપોર્ટ સાથે Vue એપ્લીકેશન બહાર પાડી, જેમાં એક નાની વિગત ખૂટે છે: અમે ક્લાયન્ટને પ્રારંભિક સ્થિતિ મોકલી નથી.

શા માટે? આ પ્રશ્નનો કોઈ ચોક્કસ જવાબ નથી. કાં તો તેઓ સર્વર તરફથી પ્રતિસાદનું કદ વધારવા માંગતા ન હતા, અથવા અન્ય આર્કિટેક્ચરલ સમસ્યાઓના સમૂહને કારણે, અથવા તે ફક્ત ઉપડ્યું ન હતું. એક રીતે અથવા બીજી રીતે, રાજ્યને બહાર ફેંકી દેવું અને સર્વરે જે કર્યું તે બધું ફરીથી વાપરવું એકદમ યોગ્ય અને ઉપયોગી લાગે છે. કાર્ય ખરેખર તુચ્છ છે - રાજ્ય ખાલી ઇન્જેક્ટ કરવામાં આવે છે એક્ઝેક્યુશન સંદર્ભમાં, અને Vue આપોઆપ વૈશ્વિક ચલ તરીકે જનરેટ કરેલા લેઆઉટમાં ઉમેરે છે: window.__INITIAL_STATE__.

જે સમસ્યાઓ ઊભી થઈ છે તેમાંની એક છે ચક્રીય માળખાને JSON માં કન્વર્ટ કરવામાં અસમર્થતા (પરિપત્ર સંદર્ભ); આવા માળખાને તેમના સપાટ સમકક્ષો સાથે બદલીને ઉકેલી શકાય છે.

વધુમાં, UGC સામગ્રી સાથે કામ કરતી વખતે, તમારે યાદ રાખવું જોઈએ કે ડેટાને HTML એન્ટિટીમાં રૂપાંતરિત કરવો જોઈએ જેથી HTML ભંગ ન થાય. આ હેતુઓ માટે અમે ઉપયોગ કરીએ છીએ he.

ફરીથી દોરવાનું ઓછું કરી રહ્યું છે

જેમ તમે ઉપરના ચિત્રમાંથી જોઈ શકો છો, અમારા કિસ્સામાં, એક નોડ JS ઉદાહરણ બે કાર્યો કરે છે: API માં SSR અને "પ્રોક્સી", જ્યાં વપરાશકર્તા અધિકૃતતા થાય છે. આ સંજોગો સર્વર પર JS કોડ ચાલી રહ્યો હોય ત્યારે અધિકૃત કરવાનું અશક્ય બનાવે છે, કારણ કે નોડ સિંગલ-થ્રેડેડ છે, અને SSR ફંક્શન સિંક્રનસ છે. એટલે કે, જ્યારે કૉલસ્ટૅક કોઈ બાબતમાં વ્યસ્ત હોય ત્યારે સર્વર ફક્ત પોતાને વિનંતીઓ મોકલી શકતું નથી. તે બહાર આવ્યું છે કે અમે રાજ્યને અપડેટ કર્યું છે, પરંતુ ઇન્ટરફેસ ટ્વિચ કરવાનું બંધ કરતું નથી, કારણ કે ક્લાયંટ પરનો ડેટા વપરાશકર્તા સત્રને ધ્યાનમાં લેતા અપડેટ કરવો પડ્યો હતો. અમારે અમારી એપ્લિકેશનને વપરાશકર્તાના લોગિનને ધ્યાનમાં લઈને, પ્રારંભિક સ્થિતિમાં સાચો ડેટા મૂકવા માટે શીખવવાની જરૂર હતી.

સમસ્યાના ફક્ત બે ઉકેલો હતા:

• ક્રોસ-સર્વર વિનંતીઓ સાથે અધિકૃતતા ડેટા જોડો;
• નોડ JS સ્તરોને બે અલગ-અલગ ઉદાહરણોમાં વિભાજિત કરો.

પ્રથમ સોલ્યુશન માટે સર્વર પર વૈશ્વિક ચલોનો ઉપયોગ જરૂરી હતો, અને બીજામાં ઓછામાં ઓછા એક મહિના સુધી કાર્ય પૂર્ણ કરવાની સમયમર્યાદા લંબાવવામાં આવી હતી.

કેવી રીતે પસંદગી કરવી? હેબ્ર ઘણીવાર ઓછામાં ઓછા પ્રતિકારના માર્ગ સાથે આગળ વધે છે. અનૌપચારિક રીતે, વિચારથી પ્રોટોટાઇપ સુધીના ચક્રને ન્યૂનતમ સુધી ઘટાડવાની સામાન્ય ઇચ્છા છે. ઉત્પાદન પ્રત્યેના વલણનું મોડલ કંઈક અંશે booking.com ના પોસ્ટ્યુલેટ્સની યાદ અપાવે છે, માત્ર એટલો જ તફાવત છે કે Habr વપરાશકર્તાના પ્રતિસાદને વધુ ગંભીરતાથી લે છે અને વિકાસકર્તા તરીકે, આવા નિર્ણયો લેવા માટે તમારા પર વિશ્વાસ રાખે છે.

આ તર્કને અનુસરીને અને સમસ્યાને ઝડપથી ઉકેલવાની મારી પોતાની ઇચ્છાને પગલે, મેં વૈશ્વિક ચલો પસંદ કર્યા. અને, જેમ વારંવાર થાય છે, તમારે વહેલા કે પછી તેમના માટે ચૂકવણી કરવી પડશે. અમે લગભગ તરત જ ચૂકવણી કરી: અમે સપ્તાહના અંતે કામ કર્યું, પરિણામો સાફ કર્યા, લખ્યું પોસ્ટ મોર્ટમ અને સર્વરને બે ભાગમાં વહેંચવાનું શરૂ કર્યું. ભૂલ ખૂબ જ મૂર્ખ હતી, અને તેમાં સામેલ બગનું પુનઃઉત્પાદન કરવું સરળ ન હતું. અને હા, આ માટે શરમજનક વાત છે, પરંતુ એક યા બીજી રીતે, ઠોકર ખાઈને, ગ્લોબલ વેરિયેબલ્સ સાથેનું મારું PoC તેમ છતાં ઉત્પાદનમાં ગયું અને નવા “ટુ-નોડ” આર્કિટેક્ચર તરફ જવાની રાહ જોતી વખતે ખૂબ સફળતાપૂર્વક કામ કરી રહ્યું છે. આ એક મહત્વપૂર્ણ પગલું હતું, કારણ કે ઔપચારિક રીતે ધ્યેય હાંસલ કરવામાં આવ્યો હતો - SSR એ સંપૂર્ણપણે ઉપયોગ માટે તૈયાર પૃષ્ઠ વિતરિત કરવાનું શીખ્યા, અને UI વધુ શાંત બન્યું.

રિફેક્ટરિંગના પ્રથમ તબક્કા પછી મોબાઇલ હેબ્ર ઇન્ટરફેસ

આખરે, મોબાઇલ સંસ્કરણનું SSR-CSR આર્કિટેક્ચર આ ચિત્ર તરફ દોરી જાય છે:

"ટુ-નોડ" SSR-CSR સર્કિટ. નોડ JS API હંમેશા અસુમેળ I/O માટે તૈયાર છે અને SSR ફંક્શન દ્વારા અવરોધિત નથી, કારણ કે બાદમાં એક અલગ ઉદાહરણમાં સ્થિત છે. ક્વેરી સાંકળ #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 },
  ...
}

લેખોની સૂચિ અહીં તે માત્ર એક પ્રકારનો લેખોનો ભંડાર છે. બધા લેખો કે જે વપરાશકર્તા સત્ર દરમિયાન ડાઉનલોડ કરવામાં આવ્યા હતા. અમે તેમની સાથે ખૂબ કાળજી રાખીએ છીએ, કારણ કે આ તે ટ્રાફિક છે જે કદાચ સ્ટેશનો વચ્ચે મેટ્રોમાં ક્યાંક પીડા દ્વારા ડાઉનલોડ કરવામાં આવ્યો હશે, અને અમે ચોક્કસપણે વપરાશકર્તાને તેની પાસે પહેલેથી જ છે તે ડેટા લોડ કરવાની ફરજ પાડીને ફરીથી આ પીડા પહોંચાડવા માંગતા નથી. ડાઉનલોડ કરેલ. એક પદાર્થ લેખ આઈડી ઑબ્જેક્ટ્સ માટે ફક્ત ID ની શ્રેણી છે (જેમ કે "લિંક"). લેખ. આ માળખું તમને રૂટ્સ માટે સામાન્ય ડેટાની નકલ કરવાનું અને ઑબ્જેક્ટનો ફરીથી ઉપયોગ કરવાનું ટાળવા દે છે લેખ પોસ્ટ પેજને તેમાં વિસ્તૃત ડેટા મર્જ કરીને રેન્ડર કરતી વખતે.

લેખોની સૂચિનું આઉટપુટ પણ વધુ પારદર્શક બન્યું છે: પુનરાવર્તક ઘટક લેખ ID સાથે એરે દ્વારા પુનરાવર્તિત થાય છે અને લેખ ટીઝર ઘટકને દોરે છે, આઇડીને પ્રોપ તરીકે પસાર કરે છે, અને બાળ ઘટક, બદલામાં, જરૂરી ડેટા પુનઃપ્રાપ્ત કરે છે. લેખોની સૂચિ. જ્યારે તમે પ્રકાશન પૃષ્ઠ પર જાઓ છો, ત્યારે અમને પહેલેથી અસ્તિત્વમાં છે તે તારીખ મળે છે લેખોની સૂચિ, અમે ગુમ થયેલ ડેટા મેળવવા માટે વિનંતી કરીએ છીએ અને તેને હાલના ઑબ્જેક્ટમાં ઉમેરીએ છીએ.

શા માટે આ અભિગમ વધુ સારો છે? જેમ મેં ઉપર લખ્યું છે તેમ, ડાઉનલોડ કરેલ ડેટાના સંદર્ભમાં આ અભિગમ વધુ નમ્ર છે અને તમને તેનો ફરીથી ઉપયોગ કરવાની મંજૂરી આપે છે. પરંતુ આ ઉપરાંત, તે કેટલીક નવી શક્યતાઓનો માર્ગ ખોલે છે જે આવા આર્કિટેક્ચરમાં સંપૂર્ણ રીતે બંધબેસે છે. ઉદાહરણ તરીકે, મતદાન કરવું અને લેખો દેખાય તે રીતે ફીડમાં લોડ કરવા. અમે ફક્ત નવીનતમ પોસ્ટ્સને "સ્ટોરેજ" માં મૂકી શકીએ છીએ લેખોની સૂચિમાં નવા ID ની અલગ યાદી સાચવો લેખ આઈડી અને તેના વિશે વપરાશકર્તાને સૂચિત કરો. જ્યારે આપણે "નવા પ્રકાશનો બતાવો" બટન પર ક્લિક કરીએ છીએ, ત્યારે અમે લેખોની વર્તમાન સૂચિની એરેની શરૂઆતમાં નવા આઈડી દાખલ કરીશું અને બધું લગભગ જાદુઈ રીતે કામ કરશે.

ડાઉનલોડ કરવાનું વધુ આનંદપ્રદ બનાવે છે

રિફેક્ટરિંગ કેક પરનો હિમસ્તર એ હાડપિંજરનો ખ્યાલ છે, જે ધીમા ઇન્ટરનેટ પર સામગ્રી ડાઉનલોડ કરવાની પ્રક્રિયાને થોડી ઓછી ઘૃણાસ્પદ બનાવે છે. આ બાબતે કોઈ ચર્ચા થઈ ન હતી; વિચારથી પ્રોટોટાઈપ સુધીના માર્ગમાં શાબ્દિક રીતે બે કલાકનો સમય લાગ્યો હતો. ડિઝાઇન વ્યવહારીક રીતે પોતાની જાતને દોરે છે, અને અમે ડેટાની રાહ જોતી વખતે અમારા ઘટકોને સરળ, ભાગ્યે જ ફ્લિકરિંગ ડિવ બ્લોક્સ રેન્ડર કરવાનું શીખવ્યું. વ્યક્તિલક્ષી રીતે, લોડિંગ માટેનો આ અભિગમ વાસ્તવમાં વપરાશકર્તાના શરીરમાં સ્ટ્રેસ હોર્મોન્સનું પ્રમાણ ઘટાડે છે. હાડપિંજર આના જેવો દેખાય છે:

હેબ્રાલોડિંગ

પ્રતિબિંબિત કરે છે

હું છ મહિનાથી હેબ્રેમાં કામ કરી રહ્યો છું અને મારા મિત્રો હજુ પણ પૂછે છે: સારું, તમને ત્યાં કેવું ગમ્યું? ઠીક છે, આરામદાયક - હા. પરંતુ કંઈક એવું છે જે આ કાર્યને અન્ય કરતા અલગ બનાવે છે. મેં એવી ટીમોમાં કામ કર્યું કે જેઓ તેમના ઉત્પાદન પ્રત્યે સંપૂર્ણપણે ઉદાસીન હતા, તેમના વપરાશકર્તાઓ કોણ છે તે જાણતા કે સમજી શક્યા ન હતા. પરંતુ અહીં બધું અલગ છે. અહીં તમે જે કરો છો તેના માટે તમે જવાબદાર અનુભવો છો. સુવિધા વિકસાવવાની પ્રક્રિયામાં, તમે આંશિક રીતે તેના માલિક બનો છો, તમારી કાર્યક્ષમતા સંબંધિત તમામ ઉત્પાદન મીટિંગ્સમાં ભાગ લો છો, સૂચનો કરો છો અને જાતે નિર્ણયો લો છો. તમે દરરોજ જાતે ઉપયોગ કરો છો તે ઉત્પાદન બનાવવું એ ખૂબ જ સરસ છે, પરંતુ એવા લોકો માટે કોડ લખવો કે જેઓ તમારા કરતાં કદાચ વધુ સારા છે તે માત્ર એક અવિશ્વસનીય લાગણી છે (કોઈ કટાક્ષ નથી).

આ બધા ફેરફારોના પ્રકાશન પછી, અમને હકારાત્મક પ્રતિસાદ મળ્યો, અને તે ખૂબ જ સરસ હતું. તે પ્રેરણાદાયી છે. આભાર! વધુ લખો.

હું તમને યાદ અપાવી દઉં કે વૈશ્વિક ચલ પછી અમે આર્કિટેક્ચર બદલવાનું અને પ્રોક્સી લેયરને અલગ દાખલામાં ફાળવવાનું નક્કી કર્યું છે. "ટુ-નોડ" આર્કિટેક્ચર સાર્વજનિક બીટા પરીક્ષણના સ્વરૂપમાં પહેલાથી જ રિલીઝ પર પહોંચી ગયું છે. હવે કોઈપણ તેના પર સ્વિચ કરી શકે છે અને અમને મોબાઈલ Habr ને વધુ સારું બનાવવામાં મદદ કરી શકે છે. આજ માટે આટલું જ. ટિપ્પણીઓમાં તમારા બધા પ્રશ્નોના જવાબ આપવા માટે મને આનંદ થશે.

સોર્સ: www.habr.com