Habr ఫ్రంట్-ఎండ్ డెవలపర్ లాగ్‌లు: రీఫ్యాక్టరింగ్ మరియు రిఫ్లెక్టింగ్

హబ్ర్ లోపలి నుండి ఎలా నిర్మించబడింది, వర్క్‌ఫ్లో ఎలా నిర్మించబడింది, కమ్యూనికేషన్‌లు ఎలా నిర్మించబడ్డాయి, ఏ ప్రమాణాలు ఉపయోగించబడతాయి మరియు సాధారణంగా ఇక్కడ కోడ్ ఎలా వ్రాయబడుతుంది అనే దానిపై నేను ఎల్లప్పుడూ ఆసక్తి కలిగి ఉన్నాను. అదృష్టవశాత్తూ, నాకు అలాంటి అవకాశం వచ్చింది, ఎందుకంటే నేను ఇటీవల హబ్రా జట్టులో భాగమయ్యాను. మొబైల్ సంస్కరణ యొక్క చిన్న రీఫ్యాక్టరింగ్ యొక్క ఉదాహరణను ఉపయోగించి, నేను ప్రశ్నకు సమాధానం ఇవ్వడానికి ప్రయత్నిస్తాను: ఇక్కడ ముందు భాగంలో పని చేయడం ఎలా ఉంటుంది. ప్రోగ్రామ్‌లో: Habrలో వ్యక్తిగత అనుభవం గురించి నోట్స్ నుండి సాస్‌తో నోడ్, Vue, Vuex మరియు SSR.

డెవలప్‌మెంట్ టీమ్ గురించి మీరు తెలుసుకోవలసిన మొదటి విషయం ఏమిటంటే, మాలో కొంతమంది ఉన్నారు. సరిపోదు - ఇవి మూడు ఫ్రంట్‌లు, రెండు బ్యాక్‌లు మరియు అన్ని హబ్ర్ యొక్క సాంకేతిక ప్రధాన - బాక్స్లీ. ఒక టెస్టర్, డిజైనర్, ముగ్గురు వాడిమ్, మిరాకిల్ చీపురు, మార్కెటింగ్ స్పెషలిస్ట్ మరియు ఇతర బంబురమ్‌లు కూడా ఉన్నారు. కానీ హబ్ర్ మూలాలకు కేవలం ఆరుగురు ప్రత్యక్ష సహకారులు మాత్రమే ఉన్నారు. ఇది చాలా అరుదు - బహుళ-మిలియన్-డాలర్ ప్రేక్షకులను కలిగి ఉన్న ప్రాజెక్ట్, ఇది బయటి నుండి ఒక పెద్ద సంస్థలా కనిపిస్తుంది, వాస్తవానికి సాధ్యమైనంత చదునైన సంస్థాగత నిర్మాణంతో అనుకూలమైన స్టార్టప్ లాగా కనిపిస్తుంది.

అనేక ఇతర IT కంపెనీల వలె, Habr చురుకైన ఆలోచనలు, CI అభ్యాసాలు మరియు అంతే. కానీ నా భావాల ప్రకారం, Habr ఒక ఉత్పత్తిగా నిరంతరంగా కంటే తరంగాలలో ఎక్కువగా అభివృద్ధి చెందుతోంది. కాబట్టి, వరుసగా అనేక స్ప్రింట్‌ల కోసం, మేము శ్రద్ధగా ఏదైనా కోడ్ చేస్తాము, డిజైన్ చేసి రీడిజైన్ చేస్తాము, ఏదైనా విచ్ఛిన్నం చేస్తాము మరియు దాన్ని సరిచేస్తాము, టిక్కెట్‌లను పరిష్కరించాము మరియు కొత్త వాటిని సృష్టించాము, ఒక రేక్‌పై అడుగు పెట్టాము మరియు చివరకు లక్షణాన్ని విడుదల చేయడానికి మనల్ని మనం కాల్చుకుంటాము. ఉత్పత్తి. ఆపై ఒక నిర్దిష్ట ప్రశాంతత, పునరాభివృద్ధి కాలం, “ముఖ్యమైనది-అత్యవసరం కాదు” క్వాడ్రంట్‌లో ఏమి చేయాలో సమయం వస్తుంది.

ఇది ఖచ్చితంగా ఈ "ఆఫ్-సీజన్" స్ప్రింట్ క్రింద చర్చించబడుతుంది. ఈసారి ఇది Habr యొక్క మొబైల్ వెర్షన్ యొక్క రీఫ్యాక్టరింగ్‌ను కలిగి ఉంది. సాధారణంగా, కంపెనీ దాని కోసం అధిక ఆశలు కలిగి ఉంది మరియు భవిష్యత్తులో ఇది హాబ్ర్ యొక్క అవతారాల మొత్తం జంతుప్రదర్శనశాలను భర్తీ చేయాలి మరియు సార్వత్రిక క్రాస్-ప్లాట్‌ఫారమ్ పరిష్కారంగా మారాలి. ఏదో ఒక రోజు అనుకూల లేఅవుట్, PWA, ఆఫ్‌లైన్ మోడ్, వినియోగదారు అనుకూలీకరణ మరియు అనేక ఇతర ఆసక్తికరమైన విషయాలు ఉంటాయి.

టాస్క్ సెట్ చేద్దాం

ఒకసారి, ఒక సాధారణ స్టాండ్-అప్‌లో, మొబైల్ వెర్షన్ యొక్క కామెంట్స్ కాంపోనెంట్ ఆర్కిటెక్చర్‌లోని సమస్యల గురించి ముందు ఒకటి మాట్లాడింది. దీన్ని దృష్టిలో ఉంచుకుని, మేము గ్రూప్ సైకోథెరపీ ఫార్మాట్‌లో మైక్రో మీటింగ్‌ని నిర్వహించాము. అందరూ వంతులవారీగా చెప్పుకుంటూ, ఎక్కడ బాధపడ్డారో, అంతా పేపర్‌లో రికార్డ్ చేసారు, సానుభూతి తెలిపారు, అర్థం చేసుకున్నారు, ఎవరూ చప్పట్లు కొట్టలేదు. ఫలితంగా 20 సమస్యల జాబితా ఉంది, ఇది మొబైల్ Habr విజయానికి ఇంకా సుదీర్ఘమైన మరియు ముళ్ల మార్గాన్ని కలిగి ఉందని స్పష్టం చేసింది.

నేను ప్రాథమికంగా వనరుల వినియోగం మరియు మృదువైన ఇంటర్‌ఫేస్ అని పిలవబడే సామర్థ్యం గురించి ఆందోళన చెందాను. ప్రతిరోజూ, హోమ్-వర్క్-హోమ్ రూట్‌లో, నా పాత ఫోన్ ఫీడ్‌లో 20 హెడ్‌లైన్‌లను ప్రదర్శించడానికి తీవ్రంగా ప్రయత్నించడం నేను చూశాను. ఇది ఇలా కనిపించింది:

రీఫ్యాక్టరింగ్ ముందు మొబైల్ Habr ఇంటర్ఫేస్

ఏమి జరుగుతుంది ఇక్కడ? సంక్షిప్తంగా, సర్వర్ HTML పేజీని అందరికీ ఒకే విధంగా అందజేస్తుంది, వినియోగదారు లాగిన్ చేసినా లేదా అనే దానితో సంబంధం లేకుండా. అప్పుడు క్లయింట్ JS లోడ్ చేయబడుతుంది మరియు అవసరమైన డేటాను మళ్లీ అభ్యర్థిస్తుంది, కానీ అధికారం కోసం సర్దుబాటు చేయబడుతుంది. అంటే, మేము ఒకే పనిని రెండుసార్లు చేసాము. ఇంటర్‌ఫేస్ మినుకుమినుకుమంటుంది మరియు వినియోగదారు మంచి వంద అదనపు కిలోబైట్‌లను డౌన్‌లోడ్ చేసారు. వివరంగా ప్రతిదీ మరింత గగుర్పాటుగా కనిపించింది.

పాత SSR-CSR పథకం. Node JS HTMLని రూపొందించడంలో బిజీగా లేనప్పుడు మరియు APIకి అభ్యర్థనలను ప్రాక్సీ చేయగలిగినప్పుడు, C3 మరియు C4 దశల్లో మాత్రమే అధికారీకరణ సాధ్యమవుతుంది.

హబ్ర్ వినియోగదారులలో ఒకరు ఆ సమయంలో మా నిర్మాణాన్ని చాలా ఖచ్చితంగా వివరించారు:

మొబైల్ వెర్షన్ చెత్తగా ఉంది. నేను అలాగే చెబుతున్నాను. SSR మరియు CSR యొక్క భయంకరమైన కలయిక.

ఎంత బాధగా ఉన్నా ఒప్పుకోవలసి వచ్చింది.

నేను ఎంపికలను అంచనా వేసాను, "ఇది ఇప్పుడు చెడ్డది, సరిగ్గా చేయి" అనే స్థాయిలో వివరణతో జిరాలో టిక్కెట్‌ను సృష్టించాను మరియు పనిని విస్తృత స్ట్రోక్‌లలో కుళ్ళిపోయాను:

• డేటాను తిరిగి ఉపయోగించడం,
• తిరిగి డ్రాల సంఖ్యను తగ్గించండి,
• నకిలీ అభ్యర్థనలను తొలగించండి,
• లోడ్ ప్రక్రియను మరింత స్పష్టంగా చేయండి.

డేటాను మళ్లీ ఉపయోగించుకుందాం

సిద్ధాంతంలో, సర్వర్-సైడ్ రెండరింగ్ రెండు సమస్యలను పరిష్కరించడానికి రూపొందించబడింది: శోధన ఇంజిన్ పరిమితుల పరంగా బాధపడకూడదు. SPA ఇండెక్సింగ్ మరియు మెట్రిక్ మెరుగుపరచండి FMP (అనివార్యంగా మరింత దిగజారుతోంది టిటిఐ) చివరకు ఒక క్లాసిక్ దృష్టాంతంలో 2013లో Airbnbలో రూపొందించబడింది సంవత్సరం (ఇప్పటికీ Backbone.jsలో ఉంది), SSR అనేది నోడ్ ఎన్విరాన్మెంట్‌లో రన్ అవుతున్న అదే ఐసోమోర్ఫిక్ JS అప్లికేషన్. సర్వర్ కేవలం అభ్యర్థనకు ప్రతిస్పందనగా రూపొందించిన లేఅవుట్‌ను పంపుతుంది. అప్పుడు రీహైడ్రేషన్ క్లయింట్ వైపు సంభవిస్తుంది, ఆపై ప్రతిదీ పేజీ రీలోడ్ లేకుండా పని చేస్తుంది. Habr కోసం, టెక్స్ట్ కంటెంట్‌తో ఉన్న అనేక ఇతర వనరుల కోసం, శోధన ఇంజిన్‌లతో స్నేహపూర్వక సంబంధాలను ఏర్పరచడంలో సర్వర్ రెండరింగ్ కీలకమైన అంశం.

సాంకేతిక పరిజ్ఞానం వచ్చినప్పటి నుండి ఆరు సంవత్సరాలకు పైగా గడిచినప్పటికీ, ఈ సమయంలో ఫ్రంట్ ఎండ్ ప్రపంచంలో వంతెన కింద చాలా నీరు నిజంగా ఎగిరింది, చాలా మంది డెవలపర్‌లకు ఈ ఆలోచన ఇప్పటికీ రహస్యంగా కప్పబడి ఉంది. మేము పక్కన నిలబడలేదు మరియు ఉత్పత్తికి SSR మద్దతుతో Vue అప్లికేషన్‌ను రూపొందించాము, ఒక చిన్న వివరాలు లేవు: మేము క్లయింట్‌కు ప్రారంభ స్థితిని పంపలేదు.

ఎందుకు? ఈ ప్రశ్నకు ఖచ్చితమైన సమాధానం లేదు. వారు సర్వర్ నుండి ప్రతిస్పందన యొక్క పరిమాణాన్ని పెంచడానికి ఇష్టపడలేదు, లేదా ఇతర నిర్మాణ సమస్యల కారణంగా లేదా అది కేవలం టేకాఫ్ కాలేదు. ఒక విధంగా లేదా మరొక విధంగా, స్థితిని విసిరివేసి, సర్వర్ చేసిన ప్రతిదాన్ని తిరిగి ఉపయోగించడం చాలా సముచితమైనది మరియు ఉపయోగకరంగా ఉంటుంది. పని నిజానికి అల్పమైనది - రాష్ట్రం కేవలం ఇంజెక్ట్ చేయబడింది అమలు సందర్భంలో, మరియు Vue స్వయంచాలకంగా గ్లోబల్ వేరియబుల్‌గా ఉత్పత్తి చేయబడిన లేఅవుట్‌కు జోడిస్తుంది: window.__INITIAL_STATE__.

తలెత్తిన సమస్యలలో ఒకటి చక్రీయ నిర్మాణాలను JSON (వృత్తాకార సూచన); అటువంటి నిర్మాణాలను వాటి ఫ్లాట్ కౌంటర్‌పార్ట్‌లతో భర్తీ చేయడం ద్వారా పరిష్కరించబడింది.

అదనంగా, UGC కంటెంట్‌తో వ్యవహరించేటప్పుడు, HTMLని విచ్ఛిన్నం చేయకుండా ఉండటానికి డేటాను HTML ఎంటిటీలుగా మార్చాలని మీరు గుర్తుంచుకోవాలి. ఈ ప్రయోజనాల కోసం మేము ఉపయోగిస్తాము he.

రీడ్రాలను తగ్గించడం

పై రేఖాచిత్రం నుండి మీరు చూడగలిగినట్లుగా, మా విషయంలో, ఒక నోడ్ JS ఉదాహరణ రెండు విధులను నిర్వహిస్తుంది: APIలో SSR మరియు “ప్రాక్సీ”, ఇక్కడ వినియోగదారు అధికారం ఏర్పడుతుంది. నోడ్ సింగిల్-థ్రెడ్ మరియు SSR ఫంక్షన్ సింక్రోనస్ అయినందున, ఈ పరిస్థితి సర్వర్‌లో JS కోడ్ రన్ అవుతున్నప్పుడు ప్రామాణీకరించడం అసాధ్యం చేస్తుంది. అంటే, కాల్‌స్టాక్ ఏదైనా పనిలో బిజీగా ఉన్నప్పుడు సర్వర్ తనకు తానుగా అభ్యర్థనలను పంపదు. మేము స్థితిని అప్‌డేట్ చేశామని తేలింది, అయితే వినియోగదారు సెషన్‌ను పరిగణనలోకి తీసుకొని క్లయింట్‌లోని డేటాను నవీకరించవలసి ఉన్నందున ఇంటర్‌ఫేస్ మెలితిప్పడం ఆపలేదు. వినియోగదారు లాగిన్‌ను పరిగణనలోకి తీసుకుని, సరైన డేటాను ప్రారంభ స్థితిలో ఉంచడానికి మేము మా అప్లికేషన్‌కు నేర్పించాల్సిన అవసరం ఉంది.

సమస్యకు కేవలం రెండు పరిష్కారాలు మాత్రమే ఉన్నాయి:

• క్రాస్-సర్వర్ అభ్యర్థనలకు అధికార డేటాను అటాచ్ చేయండి;
• నోడ్ JS లేయర్‌లను రెండు వేర్వేరు ఉదాహరణలుగా విభజించండి.

మొదటి పరిష్కారానికి సర్వర్‌లో గ్లోబల్ వేరియబుల్స్ ఉపయోగించడం అవసరం, మరియు రెండవది పనిని పూర్తి చేయడానికి గడువును కనీసం ఒక నెల పొడిగించింది.

ఎలా ఎంపిక చేసుకోవాలి? Habr తరచుగా కనీసం ప్రతిఘటన మార్గంలో కదులుతుంది. అనధికారికంగా, ఆలోచన నుండి ప్రోటోటైప్ వరకు చక్రాన్ని కనిష్టంగా తగ్గించాలనే సాధారణ కోరిక ఉంది. ఉత్పత్తి పట్ల వైఖరి యొక్క నమూనా కొంతవరకు 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 },
  ...
}

వ్యాసాల జాబితా ఇక్కడ ఇది ఒక రకమైన వ్యాసాల భాండాగారం మాత్రమే. వినియోగదారు సెషన్‌లో డౌన్‌లోడ్ చేయబడిన అన్ని కథనాలు. మేము వారితో చాలా జాగ్రత్తగా వ్యవహరిస్తాము, ఎందుకంటే ఇది స్టేషన్‌ల మధ్య మెట్రోలో ఎక్కడో నొప్పి ద్వారా డౌన్‌లోడ్ చేయబడిన ట్రాఫిక్, మరియు వినియోగదారుని ఇప్పటికే కలిగి ఉన్న డేటాను లోడ్ చేయమని బలవంతం చేయడం ద్వారా మేము ఖచ్చితంగా అతనికి ఈ బాధను కలిగించకూడదనుకుంటున్నాము. డౌన్‌లోడ్ చేయబడింది. ఒక వస్తువు వ్యాసాలుIds అనేది వస్తువులకు IDల శ్రేణి ("లింక్‌లు" వలె) వ్యాసం. ఈ నిర్మాణం రూట్‌లకు సాధారణ డేటాను నకిలీ చేయడం మరియు వస్తువును మళ్లీ ఉపయోగించడాన్ని నివారించడానికి మిమ్మల్ని అనుమతిస్తుంది వ్యాసం పొడిగించిన డేటాను విలీనం చేయడం ద్వారా పోస్ట్ పేజీని రెండర్ చేస్తున్నప్పుడు.

కథనాల జాబితా యొక్క అవుట్‌పుట్ కూడా మరింత పారదర్శకంగా మారింది: ఇటరేటర్ కాంపోనెంట్ ఆర్టికల్ IDలతో శ్రేణి ద్వారా పునరావృతమవుతుంది మరియు కథనం టీజర్ కాంపోనెంట్‌ను గీస్తుంది, Idని ప్రాప్‌గా పాస్ చేస్తుంది మరియు చైల్డ్ కాంపోనెంట్, అవసరమైన డేటాను తిరిగి పొందుతుంది వ్యాసాల జాబితా. మీరు ప్రచురణ పేజీకి వెళ్లినప్పుడు, మేము ఇప్పటికే ఉన్న తేదీని పొందుతాము వ్యాసాల జాబితా, తప్పిపోయిన డేటాను పొందేందుకు మరియు ఇప్పటికే ఉన్న ఆబ్జెక్ట్‌కు దానిని జోడించమని మేము అభ్యర్థన చేస్తాము.

ఈ విధానం ఎందుకు మంచిది? నేను పైన వ్రాసినట్లుగా, డౌన్‌లోడ్ చేయబడిన డేటాకు సంబంధించి ఈ విధానం మరింత సున్నితంగా ఉంటుంది మరియు దానిని మళ్లీ ఉపయోగించేందుకు మిమ్మల్ని అనుమతిస్తుంది. కానీ ఇది కాకుండా, అటువంటి నిర్మాణంలో సరిగ్గా సరిపోయే కొన్ని కొత్త అవకాశాలకు ఇది మార్గం తెరుస్తుంది. ఉదాహరణకు, పోల్ చేయడం మరియు కథనాలు కనిపించే విధంగా ఫీడ్‌లోకి లోడ్ చేయడం. మేము తాజా పోస్ట్‌లను “నిల్వ”లో ఉంచవచ్చు వ్యాసాల జాబితా, కొత్త IDల ప్రత్యేక జాబితాను సేవ్ చేయండి వ్యాసాలుIds మరియు దాని గురించి వినియోగదారుకు తెలియజేయండి. మేము "కొత్త ప్రచురణలను చూపు" బటన్‌పై క్లిక్ చేసినప్పుడు, మేము ప్రస్తుత కథనాల జాబితా యొక్క శ్రేణి ప్రారంభంలో కొత్త ఐడిలను ఇన్‌సర్ట్ చేస్తాము మరియు ప్రతిదీ దాదాపు అద్భుతంగా పని చేస్తుంది.

డౌన్‌లోడ్‌ను మరింత ఆనందదాయకంగా మారుస్తోంది

రీఫ్యాక్టరింగ్ కేక్‌పై ఐసింగ్ అనేది అస్థిపంజరాల భావన, ఇది నెమ్మదిగా ఉన్న ఇంటర్నెట్‌లో కంటెంట్‌ను డౌన్‌లోడ్ చేసే ప్రక్రియను కొద్దిగా అసహ్యంగా చేస్తుంది. ఈ విషయంపై చర్చలు లేవు; ఆలోచన నుండి నమూనాకు మార్గం అక్షరాలా రెండు గంటలు పట్టింది. డిజైన్ ఆచరణాత్మకంగా దానికదే రూపొందించబడింది మరియు డేటా కోసం వేచి ఉన్నప్పుడు సరళమైన, కేవలం మినుకుమినుకుమనే div బ్లాక్‌లను రెండర్ చేయడానికి మేము మా భాగాలకు నేర్పించాము. సబ్జెక్టివ్‌గా, లోడ్ చేయడానికి ఈ విధానం వాస్తవానికి వినియోగదారు శరీరంలో ఒత్తిడి హార్మోన్ల మొత్తాన్ని తగ్గిస్తుంది. అస్థిపంజరం ఇలా కనిపిస్తుంది:

హబ్రాలోడింగ్

ప్రతిబింబిస్తోంది

నేను హబ్రేలో ఆరు నెలలుగా పని చేస్తున్నాను మరియు నా స్నేహితులు ఇప్పటికీ అడిగారు: సరే, మీరు అక్కడ ఎలా ఇష్టపడతారు? సరే, సౌకర్యవంతంగా - అవును. కానీ ఈ పనిని ఇతరులకు భిన్నంగా చేసేది ఏదో ఉంది. నేను వారి ఉత్పత్తి పట్ల పూర్తిగా ఉదాసీనంగా ఉండే టీమ్‌లలో పనిచేశాను, వారి వినియోగదారులెవరో తెలియదు లేదా అర్థం కాలేదు. కానీ ఇక్కడ ప్రతిదీ భిన్నంగా ఉంటుంది. ఇక్కడ మీరు చేసే పనికి మీరు బాధ్యత వహిస్తారు. లక్షణాన్ని అభివృద్ధి చేసే ప్రక్రియలో, మీరు పాక్షికంగా దాని యజమాని అవుతారు, మీ కార్యాచరణకు సంబంధించిన అన్ని ఉత్పత్తి సమావేశాలలో పాల్గొనండి, సూచనలు చేయండి మరియు మీరే నిర్ణయాలు తీసుకోండి. మీరు ప్రతిరోజూ ఉపయోగించే ఒక ఉత్పత్తిని మీరే తయారు చేసుకోవడం చాలా బాగుంది, అయితే మీ కంటే మెరుగ్గా ఉన్న వ్యక్తుల కోసం కోడ్ రాయడం అనేది ఒక అద్భుతమైన అనుభూతి (వ్యంగ్యం లేదు).

ఈ మార్పులన్నింటినీ విడుదల చేసిన తర్వాత, మేము సానుకూల అభిప్రాయాన్ని పొందాము మరియు ఇది చాలా చాలా బాగుంది. ఇది స్ఫూర్తిదాయకం. ధన్యవాదాలు! ఇంకా వ్రాయండి.

గ్లోబల్ వేరియబుల్స్ తర్వాత మేము ఆర్కిటెక్చర్‌ను మార్చాలని మరియు ప్రాక్సీ లేయర్‌ను ప్రత్యేక ఉదాహరణగా కేటాయించాలని నిర్ణయించుకున్నామని నేను మీకు గుర్తు చేస్తున్నాను. "టూ-నోడ్" ఆర్కిటెక్చర్ పబ్లిక్ బీటా టెస్టింగ్ రూపంలో ఇప్పటికే విడుదలకు చేరుకుంది. ఇప్పుడు ఎవరైనా దీనికి మారవచ్చు మరియు మొబైల్ Habrని మెరుగుపరచడంలో మాకు సహాయపడవచ్చు. నేటికీ అంతే. వ్యాఖ్యలలో మీ అన్ని ప్రశ్నలకు సమాధానం ఇవ్వడానికి నేను సంతోషిస్తాను.

మూలం: www.habr.com