ஹப்ர் முன்-இறுதி டெவலப்பர் பதிவுகள்: மறுசீரமைப்பு மற்றும் பிரதிபலிப்பு

உள்ளே இருந்து Habr எவ்வாறு கட்டமைக்கப்படுகிறது, பணிப்பாய்வு எவ்வாறு கட்டமைக்கப்படுகிறது, தகவல்தொடர்புகள் எவ்வாறு கட்டமைக்கப்படுகின்றன, என்ன தரநிலைகள் பயன்படுத்தப்படுகின்றன மற்றும் குறியீடு பொதுவாக இங்கு எவ்வாறு எழுதப்படுகிறது என்பதில் நான் எப்போதும் ஆர்வமாக உள்ளேன். அதிர்ஷ்டவசமாக, எனக்கு அத்தகைய வாய்ப்பு கிடைத்தது, ஏனென்றால் நான் சமீபத்தில் ஹப்ரா அணியின் ஒரு பகுதியாக ஆனேன். மொபைல் பதிப்பின் சிறிய மறுசீரமைப்பின் உதாரணத்தைப் பயன்படுத்தி, நான் கேள்விக்கு பதிலளிக்க முயற்சிப்பேன்: முன்புறத்தில் இங்கே வேலை செய்வது எப்படி இருக்கும். திட்டத்தில்: ஹப்ரில் தனிப்பட்ட அனுபவத்தைப் பற்றிய குறிப்புகளிலிருந்து சாஸுடன் நோட், வ்யூ, வூக்ஸ் மற்றும் எஸ்எஸ்ஆர்.

மேம்பாட்டுக் குழுவைப் பற்றி நீங்கள் தெரிந்து கொள்ள வேண்டிய முதல் விஷயம் என்னவென்றால், எங்களில் சிலர் இருக்கிறார்கள். போதாது - இவை மூன்று முன்பக்கங்கள், இரண்டு பின்புறங்கள் மற்றும் அனைத்து Habr - Baxley தொழில்நுட்ப முன்னணி. நிச்சயமாக, ஒரு சோதனையாளர், ஒரு வடிவமைப்பாளர், மூன்று வாடிம், ஒரு அதிசய விளக்குமாறு, ஒரு சந்தைப்படுத்தல் நிபுணர் மற்றும் பிற பம்பரங்களும் உள்ளனர். ஆனால் ஹப்ரின் ஆதாரங்களுக்கு ஆறு நேரடி பங்களிப்பாளர்கள் மட்டுமே உள்ளனர். இது மிகவும் அரிதானது - பல மில்லியன் டாலர் பார்வையாளர்களைக் கொண்ட ஒரு திட்டம், வெளியில் இருந்து ஒரு மாபெரும் நிறுவனமாகத் தெரிகிறது, உண்மையில் தட்டையான நிறுவன கட்டமைப்பைக் கொண்ட வசதியான தொடக்கமாகத் தெரிகிறது.

பல ஐடி நிறுவனங்களைப் போலவே, ஹப்ரும் சுறுசுறுப்பான யோசனைகள், சிஐ நடைமுறைகள் மற்றும் அவ்வளவுதான். ஆனால் எனது உணர்வுகளின்படி, ஹப்ர் ஒரு தயாரிப்பாக தொடர்ந்து அலைகளை விட அதிகமாக உருவாகி வருகிறது. எனவே, தொடர்ச்சியாக பல ஸ்பிரிண்டுகளுக்கு, நாங்கள் விடாமுயற்சியுடன் எதையாவது குறியிடுகிறோம், வடிவமைத்து மறுவடிவமைப்பு செய்கிறோம், எதையாவது உடைத்து அதை சரிசெய்து, டிக்கெட்டுகளைத் தீர்த்து புதியவற்றை உருவாக்குகிறோம், ஒரு ரேக்கில் காலடி எடுத்து வைத்து, இறுதியாக அம்சத்தை வெளியிடுவோம். உற்பத்தி. பின்னர் ஒரு குறிப்பிட்ட அமைதி, மறுவளர்ச்சியின் காலம், "முக்கியமான-அவசரம் அல்ல" நால்வரில் உள்ளதைச் செய்வதற்கான நேரம் வருகிறது.

இது துல்லியமாக இந்த "ஆஃப்-சீசன்" ஸ்பிரிண்ட் தான் கீழே விவாதிக்கப்படும். இந்த முறை ஹப்ரின் மொபைல் பதிப்பின் மறுஉருவாக்கம் சேர்க்கப்பட்டுள்ளது. பொதுவாக, நிறுவனம் அதன் மீது அதிக நம்பிக்கை வைத்துள்ளது, மேலும் எதிர்காலத்தில் அது ஹப்ரின் அவதாரங்களின் முழு மிருகக்காட்சிசாலையையும் மாற்றி உலகளாவிய குறுக்கு-தளம் தீர்வாக மாற வேண்டும். ஒரு நாள் தகவமைப்பு தளவமைப்பு, PWA, ஆஃப்லைன் பயன்முறை, பயனர் தனிப்பயனாக்கம் மற்றும் பல சுவாரஸ்யமான விஷயங்கள் இருக்கும்.

பணியை அமைப்போம்

ஒருமுறை, ஒரு சாதாரண ஸ்டாண்ட்-அப்பில், மொபைல் பதிப்பின் கருத்துக் கூறுகளின் கட்டமைப்பில் உள்ள சிக்கல்களைப் பற்றி முன்னோடி ஒருவர் பேசினார். இதைக் கருத்தில் கொண்டு, குரூப் சைக்கோதெரபி முறையில் மைக்ரோ மீட்டிங் நடத்தினோம். எல்லாரும் மாறி மாறி எங்க வலிக்குது, எல்லாத்தையும் பேப்பரில் பதிவு செய்தார்கள், அனுதாபம் காட்டினார்கள், புரிந்து கொண்டார்கள் தவிர யாரும் கைதட்டவில்லை. இதன் விளைவாக 20 சிக்கல்களின் பட்டியல் இருந்தது, இது மொபைல் Habr இன்னும் வெற்றிக்கான நீண்ட மற்றும் முட்கள் நிறைந்த பாதையைக் கொண்டுள்ளது என்பதை தெளிவுபடுத்தியது.

நான் முதன்மையாக வள பயன்பாட்டின் செயல்திறன் மற்றும் மென்மையான இடைமுகம் என்று அழைக்கப்படுவதைப் பற்றி அக்கறை கொண்டிருந்தேன். ஒவ்வொரு நாளும், ஹோம்-வொர்க்-ஹோம் ரூட்டில், எனது பழைய ஃபோன் ஊட்டத்தில் 20 தலைப்புச் செய்திகளைக் காட்ட தீவிரமாக முயற்சிப்பதைப் பார்த்தேன். இது இப்படி இருந்தது:

மறுசீரமைப்புக்கு முன் மொபைல் Habr இடைமுகம்

இங்கே என்ன நடந்து கொண்டிருக்கின்றது? சுருக்கமாக, பயனர் உள்நுழைந்துள்ளாரா இல்லையா என்பதைப் பொருட்படுத்தாமல், சேவையகம் அனைவருக்கும் HTML பக்கத்தை ஒரே மாதிரியாக வழங்கியது. பின்னர் கிளையன்ட் JS ஏற்றப்பட்டு, தேவையான தரவை மீண்டும் கோருகிறது, ஆனால் அங்கீகாரத்திற்காக சரிசெய்யப்பட்டது. அதாவது, ஒரே வேலையை இரண்டு முறை செய்தோம். இடைமுகம் ஒளிர்ந்தது, மேலும் பயனர் நூறு கூடுதல் கிலோபைட்களை பதிவிறக்கம் செய்தார். விரிவாக எல்லாம் இன்னும் தவழும் பார்த்தேன்.

பழைய SSR-CSR திட்டம். C3 மற்றும் C4 நிலைகளில் மட்டுமே அங்கீகாரம் சாத்தியமாகும், Node JS HTML ஐ உருவாக்குவதில் மும்முரமாக இல்லாதபோது மற்றும் API க்கு கோரிக்கைகளை ப்ராக்ஸி செய்ய முடியும்.

அந்தக் காலத்தின் எங்கள் கட்டிடக்கலை ஹப்ர் பயனர்களில் ஒருவரால் மிகவும் துல்லியமாக விவரிக்கப்பட்டது:

மொபைல் பதிப்பு அபத்தமானது. நான் அதை அப்படியே சொல்கிறேன். SSR மற்றும் CSR ஆகியவற்றின் பயங்கரமான கலவை.

எவ்வளவு வருத்தமாக இருந்தாலும் ஒப்புக்கொள்ள வேண்டியிருந்தது.

நான் விருப்பங்களை மதிப்பீடு செய்தேன், ஜிராவில் ஒரு டிக்கெட்டை உருவாக்கி, "இப்போது மோசமாக உள்ளது, அதைச் சரியாகச் செய்யுங்கள்" என்ற அளவில் விளக்கத்துடன், பணியை பரந்த பக்கவாட்டில் சிதைத்தேன்:

• தரவுகளை மீண்டும் பயன்படுத்துதல்,
• மறு வரைவுகளின் எண்ணிக்கையைக் குறைத்தல்,
• நகல் கோரிக்கைகளை அகற்றவும்,
• ஏற்றுதல் செயல்முறையை இன்னும் தெளிவாக்கவும்.

தரவை மீண்டும் பயன்படுத்துவோம்

கோட்பாட்டில், சர்வர்-சைட் ரெண்டரிங் இரண்டு சிக்கல்களைத் தீர்க்க வடிவமைக்கப்பட்டுள்ளது: தேடுபொறி வரம்புகளால் பாதிக்கப்படக்கூடாது SPA அட்டவணைப்படுத்தல் மற்றும் மெட்ரிக்கை மேம்படுத்தவும் எஃப்எம்பி (தவிர்க்க முடியாமல் மோசமாகிறது TTI) ஒரு உன்னதமான சூழ்நிலையில் அது இறுதியாக 2013 இல் Airbnb இல் உருவாக்கப்பட்டது ஆண்டு (இன்னும் Backbone.js இல் உள்ளது), SSR என்பது நோட் சூழலில் இயங்கும் அதே ஐசோமார்பிக் JS பயன்பாடாகும். சேவையகம் கோரிக்கைக்கு பதிலளிக்கும் வகையில் உருவாக்கப்பட்ட தளவமைப்பை அனுப்புகிறது. பின்னர் கிளையன்ட் பக்கத்தில் ரீஹைட்ரேஷன் ஏற்படுகிறது, பின்னர் எல்லாம் பக்கம் மறுஏற்றம் இல்லாமல் வேலை செய்கிறது. ஹப்ரைப் பொறுத்தவரை, உரை உள்ளடக்கத்துடன் கூடிய பல ஆதாரங்களைப் போலவே, சர்வர் ரெண்டரிங் என்பது தேடுபொறிகளுடன் நட்புறவை வளர்ப்பதில் ஒரு முக்கிய அங்கமாகும்.

தொழில்நுட்பத்தின் வருகையிலிருந்து ஆறு ஆண்டுகளுக்கும் மேலாகிவிட்ட போதிலும், இந்த நேரத்தில் முன்-இறுதி உலகில் பாலத்தின் அடியில் நிறைய தண்ணீர் பறந்தது என்ற போதிலும், பல டெவலப்பர்களுக்கு இந்த யோசனை இன்னும் ரகசியமாக மறைக்கப்பட்டுள்ளது. நாங்கள் ஒதுங்கி நிற்கவில்லை மற்றும் SSR ஆதரவுடன் Vue பயன்பாட்டை உருவாக்கினோம், ஒரு சிறிய விவரம் இல்லை: கிளையண்டிற்கு ஆரம்ப நிலையை நாங்கள் அனுப்பவில்லை.

ஏன்? இந்த கேள்விக்கு சரியான பதில் இல்லை. ஒன்று அவர்கள் சேவையகத்திலிருந்து பதிலின் அளவை அதிகரிக்க விரும்பவில்லை, அல்லது பிற கட்டடக்கலை சிக்கல்கள் காரணமாக, அல்லது அது வெறுமனே எடுக்கவில்லை. ஒரு வழி அல்லது வேறு, நிலையைத் தூக்கி எறிந்துவிட்டு, சர்வர் செய்த அனைத்தையும் மீண்டும் பயன்படுத்துவது மிகவும் பொருத்தமானதாகவும் பயனுள்ளதாகவும் தெரிகிறது. பணி உண்மையில் அற்பமானது - மாநிலம் வெறுமனே உட்செலுத்தப்படுகிறது செயல்படுத்தல் சூழலில், மற்றும் Vue தானாகவே உலகளாவிய மாறியாக உருவாக்கப்பட்ட தளவமைப்பில் சேர்க்கிறது: window.__INITIAL_STATE__.

எழும் சிக்கல்களில் ஒன்று சுழற்சி கட்டமைப்புகளை JSON ஆக மாற்ற இயலாமை (வட்ட குறிப்பு); அத்தகைய கட்டமைப்புகளை அவற்றின் தட்டையான சகாக்களுடன் மாற்றுவதன் மூலம் தீர்க்கப்பட்டது.

கூடுதலாக, UGC உள்ளடக்கத்தைக் கையாளும் போது, ​​HTML ஐ உடைக்காமல் இருக்க, தரவு HTML நிறுவனங்களாக மாற்றப்பட வேண்டும் என்பதை நினைவில் கொள்ள வேண்டும். இந்த நோக்கங்களுக்காக நாங்கள் பயன்படுத்துகிறோம் he.

மீண்டும் வரைதல்களைக் குறைத்தல்

மேலே உள்ள வரைபடத்திலிருந்து நீங்கள் பார்க்க முடியும், எங்கள் விஷயத்தில், ஒரு முனை JS நிகழ்வு இரண்டு செயல்பாடுகளைச் செய்கிறது: SSR மற்றும் API இல் "ப்ராக்ஸி", அங்கு பயனர் அங்கீகாரம் ஏற்படுகிறது. இந்த சூழ்நிலையானது சர்வரில் JS குறியீடு இயங்கும் போது அங்கீகரிக்க இயலாது, ஏனெனில் முனை ஒற்றை-த்ரெட் மற்றும் SSR செயல்பாடு ஒத்திசைவாக உள்ளது. அதாவது, கால்ஸ்டாக் ஏதாவது பிஸியாக இருக்கும்போது சேவையகம் தனக்குத்தானே கோரிக்கைகளை அனுப்ப முடியாது. நாங்கள் நிலையை புதுப்பித்துள்ளோம், ஆனால் இடைமுகம் இழுப்பதை நிறுத்தவில்லை, ஏனெனில் பயனர் அமர்வை கணக்கில் எடுத்துக்கொண்டு கிளையண்டில் உள்ள தரவு புதுப்பிக்கப்பட வேண்டும். பயனரின் உள்நுழைவைக் கருத்தில் கொண்டு, சரியான தரவை ஆரம்ப நிலையில் வைக்க எங்கள் பயன்பாட்டிற்குக் கற்பிக்க வேண்டும்.

பிரச்சனைக்கு இரண்டு தீர்வுகள் மட்டுமே இருந்தன:

• குறுக்கு-சேவையக கோரிக்கைகளுக்கு அங்கீகாரத் தரவை இணைக்கவும்;
• Node JS அடுக்குகளை இரண்டு தனித்தனி நிகழ்வுகளாக பிரிக்கவும்.

முதல் தீர்வுக்கு சர்வரில் உலகளாவிய மாறிகளைப் பயன்படுத்த வேண்டும், இரண்டாவது பணியை முடிப்பதற்கான காலக்கெடுவை குறைந்தது ஒரு மாதமாவது நீட்டித்தது.

எப்படி தேர்வு செய்வது? ஹப்ர் பெரும்பாலும் குறைந்த எதிர்ப்பின் பாதையில் செல்கிறது. முறைசாரா முறையில், யோசனையிலிருந்து முன்மாதிரிக்கான சுழற்சியை குறைந்தபட்சமாகக் குறைக்க ஒரு பொதுவான விருப்பம் உள்ளது. தயாரிப்பு மீதான அணுகுமுறையின் மாதிரியானது booking.com இன் போஸ்டுலேட்டுகளை ஓரளவு நினைவூட்டுகிறது, ஒரே வித்தியாசம் என்னவென்றால், Habr பயனர் கருத்துக்களை மிகவும் தீவிரமாக எடுத்துக்கொள்கிறார் மற்றும் ஒரு டெவலப்பராக, அத்தகைய முடிவுகளை எடுக்க உங்களை நம்புகிறார்.

இந்த தர்க்கத்தையும், சிக்கலை விரைவாக தீர்க்கும் எனது சொந்த விருப்பத்தையும் பின்பற்றி, நான் உலகளாவிய மாறிகளைத் தேர்ந்தெடுத்தேன். மேலும், அடிக்கடி நடக்கும், நீங்கள் விரைவில் அல்லது பின்னர் அவர்களுக்கு பணம் செலுத்த வேண்டும். நாங்கள் உடனடியாக பணம் செலுத்தினோம்: நாங்கள் வார இறுதியில் வேலை செய்தோம், விளைவுகளை சுத்தம் செய்தோம், எழுதினோம் பிரேத பரிசோதனை மற்றும் சர்வரை இரண்டு பகுதிகளாகப் பிரிக்கத் தொடங்கியது. பிழை மிகவும் முட்டாள்தனமானது, மேலும் அதில் உள்ள பிழையை இனப்பெருக்கம் செய்வது எளிதல்ல. ஆம், இது ஒரு அவமானம், ஆனால் ஒரு வழி அல்லது வேறு, தடுமாறி முணுமுணுத்தாலும், உலகளாவிய மாறிகள் கொண்ட எனது PoC உற்பத்தியில் இறங்கியது மற்றும் ஒரு புதிய "இரண்டு-முனை" கட்டமைப்பிற்கான நகர்வுக்காக காத்திருக்கும் போது மிகவும் வெற்றிகரமாக செயல்படுகிறது. இது ஒரு முக்கியமான படியாகும், ஏனெனில் முறையாக இலக்கு அடையப்பட்டது - SSR முற்றிலும் பயன்படுத்த தயாராக இருக்கும் பக்கத்தை வழங்க கற்றுக்கொண்டது, மேலும் UI மிகவும் அமைதியானது.

மறுசீரமைப்பின் முதல் கட்டத்திற்குப் பிறகு மொபைல் ஹாப்ர் இடைமுகம்

இறுதியில், மொபைல் பதிப்பின் SSR-CSR கட்டமைப்பு இந்தப் படத்திற்கு வழிவகுக்கிறது:

"இரண்டு முனை" SSR-CSR சுற்று. Node 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 },
  ...
}

கட்டுரைகள் பட்டியல் இங்கே இது ஒரு வகையான கட்டுரைகளின் களஞ்சியமாகும். பயனர் அமர்வின் போது பதிவிறக்கம் செய்யப்பட்ட அனைத்து கட்டுரைகளும். நாங்கள் அவர்களை மிகுந்த கவனத்துடன் நடத்துகிறோம், ஏனெனில் இது ரயில் நிலையங்களுக்கு இடையே உள்ள மெட்ரோவில் எங்காவது வலியின் மூலம் பதிவிறக்கம் செய்யப்பட்ட ட்ராஃபிக் ஆகும், மேலும் அவர் ஏற்கனவே வைத்திருக்கும் தரவை ஏற்றும்படி கட்டாயப்படுத்துவதன் மூலம் பயனருக்கு இந்த வலியை மீண்டும் ஏற்படுத்த நாங்கள் நிச்சயமாக விரும்பவில்லை. பதிவிறக்கம் செய்யப்பட்டது. ஒரு பொருள் கட்டுரைகள்ஐடிகள் பொருள்களுக்கான ஐடிகளின் வரிசை ("இணைப்புகள்" போன்றவை). கட்டுரை. இந்த அமைப்பு வழிகளுக்கு பொதுவான தரவை நகலெடுப்பதையும் பொருளை மீண்டும் பயன்படுத்துவதையும் தவிர்க்க உங்களை அனுமதிக்கிறது கட்டுரை நீட்டிக்கப்பட்ட தரவை இணைப்பதன் மூலம் இடுகைப் பக்கத்தை வழங்கும்போது.

கட்டுரைகளின் பட்டியலின் வெளியீடும் மிகவும் வெளிப்படையானதாக மாறியுள்ளது: இட்டேட்டர் கூறு கட்டுரை ஐடிகளுடன் வரிசையின் மூலம் மீண்டும் செயல்படுகிறது மற்றும் கட்டுரையின் டீஸர் கூறுகளை வரைந்து, ஐடியை ஒரு முட்டுக்கட்டையாக அனுப்புகிறது, மேலும் குழந்தை கூறு, தேவையான தரவை மீட்டெடுக்கிறது. கட்டுரைகள் பட்டியல். நீங்கள் வெளியீட்டுப் பக்கத்திற்குச் செல்லும்போது, ​​ஏற்கனவே இருக்கும் தேதியைப் பெறுகிறோம் கட்டுரைகள் பட்டியல், விடுபட்ட தரவைப் பெற்று, ஏற்கனவே உள்ள பொருளில் அதைச் சேர்க்க நாங்கள் கோரிக்கை வைக்கிறோம்.

இந்த அணுகுமுறை ஏன் சிறந்தது? நான் மேலே எழுதியது போல, பதிவிறக்கம் செய்யப்பட்ட தரவைப் பொறுத்தவரை இந்த அணுகுமுறை மிகவும் மென்மையானது மற்றும் அதை மீண்டும் பயன்படுத்த உங்களை அனுமதிக்கிறது. ஆனால் இது தவிர, அத்தகைய கட்டிடக்கலைக்கு சரியாக பொருந்தக்கூடிய சில புதிய சாத்தியங்களுக்கான வழியைத் திறக்கிறது. எடுத்துக்காட்டாக, கருத்துக் கணிப்பு மற்றும் கட்டுரைகள் தோன்றும் போது அவற்றை ஊட்டத்தில் ஏற்றுதல். நாம் சமீபத்திய இடுகைகளை "சேமிப்பகத்தில்" வைக்கலாம். கட்டுரைகள் பட்டியல், புதிய ஐடிகளின் தனி பட்டியலை இதில் சேமிக்கவும் கட்டுரைகள்ஐடிகள் மற்றும் அதைப் பற்றி பயனருக்கு தெரிவிக்கவும். "புதிய வெளியீடுகளைக் காண்பி" பொத்தானைக் கிளிக் செய்யும் போது, ​​தற்போதைய கட்டுரைகளின் வரிசையின் தொடக்கத்தில் புதிய ஐடிகளைச் செருகுவோம், எல்லாமே கிட்டத்தட்ட மாயமாக வேலை செய்யும்.

பதிவிறக்கத்தை மேலும் சுவாரஸ்யமாக்குகிறது

மறுசீரமைப்பு கேக்கில் ஐசிங் என்பது எலும்புக்கூடுகளின் கருத்தாகும், இது மெதுவான இணையத்தில் உள்ளடக்கத்தைப் பதிவிறக்கும் செயல்முறையை சிறிது கேவலமானதாக ஆக்குகிறது. இந்த விஷயத்தில் எந்த விவாதமும் இல்லை; யோசனையிலிருந்து முன்மாதிரிக்கான பாதை உண்மையில் இரண்டு மணிநேரம் ஆனது. வடிவமைப்பு நடைமுறையில் தன்னைத்தானே ஈர்த்தது, மேலும் தரவுக்காகக் காத்திருக்கும் போது எளிமையான, அரிதாகவே ஒளிரும் டிவ் பிளாக்குகளை வழங்க எங்கள் கூறுகளுக்குக் கற்றுக் கொடுத்தோம். அகநிலை ரீதியாக, ஏற்றுவதற்கான இந்த அணுகுமுறை உண்மையில் பயனரின் உடலில் உள்ள அழுத்த ஹார்மோன்களின் அளவைக் குறைக்கிறது. எலும்புக்கூடு இதுபோல் தெரிகிறது:

ஹப்ராலோடிங்

பிரதிபலிக்கிறது

நான் ஆறு மாதங்களாக ஹப்ரேயில் வேலை செய்கிறேன், என் நண்பர்கள் இன்னும் கேட்கிறார்கள்: சரி, நீங்கள் அதை எப்படி விரும்புகிறீர்கள்? சரி, வசதியானது - ஆம். ஆனால் இந்த வேலையை மற்றவர்களிடமிருந்து வேறுபடுத்தும் ஒன்று உள்ளது. நான் அவர்களின் தயாரிப்புகளில் முற்றிலும் அலட்சியமாக இருந்த குழுக்களில் பணிபுரிந்தேன், அவர்களின் பயனர்கள் யார் என்று தெரியவில்லை அல்லது புரியவில்லை. ஆனால் இங்கே எல்லாம் வித்தியாசமானது. இங்கே நீங்கள் செய்யும் செயல்களுக்கு நீங்கள் பொறுப்பாக உணர்கிறீர்கள். ஒரு அம்சத்தை உருவாக்கும் செயல்பாட்டில், நீங்கள் ஓரளவு அதன் உரிமையாளராகி, உங்கள் செயல்பாடு தொடர்பான அனைத்து தயாரிப்பு சந்திப்புகளிலும் பங்கேற்கவும், பரிந்துரைகளை உருவாக்கவும் மற்றும் முடிவுகளை நீங்களே எடுக்கவும். ஒவ்வொரு நாளும் நீங்கள் பயன்படுத்தும் ஒரு தயாரிப்பை நீங்களே உருவாக்குவது மிகவும் அருமையாக இருக்கிறது, ஆனால் உங்களை விட சிறந்த நபர்களுக்கு குறியீட்டை எழுதுவது ஒரு நம்பமுடியாத உணர்வு (கிண்டல் இல்லை).

இந்த மாற்றங்கள் அனைத்தும் வெளியான பிறகு, நாங்கள் நேர்மறையான கருத்துக்களைப் பெற்றோம், அது மிகவும் நன்றாக இருந்தது. இது ஊக்கமளிக்கிறது. நன்றி! இன்னும் எழுதுங்கள்.

உலகளாவிய மாறிகளுக்குப் பிறகு, கட்டமைப்பை மாற்றவும், ப்ராக்ஸி லேயரை ஒரு தனி நிகழ்வாக ஒதுக்கவும் முடிவு செய்தோம் என்பதை நினைவூட்டுகிறேன். "இரண்டு-முனை" கட்டமைப்பு ஏற்கனவே பொது பீட்டா சோதனை வடிவத்தில் வெளியீட்டை எட்டியுள்ளது. இப்போது எவரும் அதற்கு மாறலாம் மற்றும் மொபைல் Habr ஐ சிறந்ததாக்க எங்களுக்கு உதவலாம். இன்னைக்கு அவ்வளவுதான். கருத்துகளில் உங்கள் எல்லா கேள்விகளுக்கும் பதிலளிப்பதில் நான் மகிழ்ச்சியடைவேன்.

ஆதாரம்: www.habr.com