Progressive Progressive Web Apps

Paul Kinlan
Available in: English (Original) Deutsch Español Français 日本語 मानक हिन्दी русский язык tiếng Việt bahasa Indonesia

நான் விரும்புகிறேன் முற்போக்கு வலை பயன்பாடுகள். நல்ல, திடமான, நம்பகமான வலைத்தளங்கள் மற்றும் பயன்பாடுகளை எப்படி உருவாக்குவது என்பது எனக்குத் தெரியும். நான் PWA மாதிரியை வேலை செய்ய உதவுகிறது - சேவைத் தொழிலாளி - கொள்கை மேடை API ஐ விரும்புகிறேன்.

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

ஆப் ஷெல்

ஆப் ஷெல் மாடல் ஒரு “SPA” (ஒற்றை பக்க பயன்பாடு) & mdash; நீங்கள் ஷெல் ஏற்ற, பின்னர் ஒவ்வொரு அடுத்த வழிசெலுத்தல் நேரடியாக உங்கள் பக்கம் JS மூலம் கையாளப்படுகிறது. இது பல சந்தர்ப்பங்களில் நன்றாக வேலை செய்கிறது.

நான் பயன்பாட்டை ஷெல் * மட்டுமே * அல்லது சிறந்த மாதிரி belize இல்லை, மற்றும் எப்போதும் உங்கள் விருப்பத்தை நிலைமை இருந்து நிலைமை வேறுபடுகிறது; உதாரணமாக என் சொந்த வலைப்பதிவில் ஒரு எளிய “ஸ்டேல்-வெல்ஸ்ட்-ரெலிகேட்” முறை பயன்படுத்துகிறது, ஒவ்வொரு பக்கமும் தேடப்படும் போது, ​​ஒவ்வொரு பக்கமும் தேக்கப்பட்டு, புதுப்பித்தலில் புதுப்பிப்புகள் காட்டப்படும்; இந்த இடுகையில் நான் சமீபத்தில் பரிசோதித்த ஒரு மாதிரி ஆராய விரும்புகிறேன்.

ஷெல் ஆப் அல்லது ஆப் ஷெல் அல்ல

ஆப் ஷெல்லின் சிறந்த மாதிரியில், முற்போக்கான செயல்திட்டத்தை ஆதரிக்க கிட்டத்தட்ட இயலாது மற்றும் பின்வரும் பண்புகளை வைத்திருக்கும் சேவை ஊழியருடன் ஒரு தளத்தை உருவாக்குவதற்கான ஒரு உண்மையான “முற்போக்கு” மாதிரியை நான் அடைய விரும்பினேன்:

  • இது JS இல்லாமல் வேலை செய்கிறது
  • ஒரு சேவை ஊழியருக்கு எந்த ஆதாரமும் இல்லை
  • இது வேகமானது

நான் எப்போதும் உருவாக்க விரும்பிய ஒரு திட்டத்தை உருவாக்குவதன் மூலம் இதை நிரூபிப்பதற்கு நான் அமைத்தேன்: நியூஸ் ரிவர் + ட்வீட் டிக் ஹைப்ரிட். கொடுக்கப்பட்ட RSS தொகுப்புகளின் தொகுப்பை அவர்கள் ஒரு பத்தியில் பாணியில் வழங்குகிறார்கள்.

உணவு டெக் - ஸ்டைலிங் புறக்கணிக்க தயவு செய்து

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

நான் இதை மிகவும் அடைந்துவிட்டேன், இந்த செயல்முறையின் போது நிறைய கற்றுக்கொண்டேன். சில விஷயங்களை இன்னும் JS தேவை, ஆனால் JS இல்லாமல் கோட்பாடு செயல்பாடுகளை பயன்பாடு; DOM API களுடன் பொதுவான NodeJS க்காக நீண்ட காலத்திற்கு நான் நீண்ட காலம் இருக்கிறேன்; நான் முற்றிலும் அதை Chrome OS இல் Glitch உடன் கட்டினேன், ஆனால் இந்த இறுதி துண்டு மற்றொரு நாள் ஒரு கதை.

நான் “படைப்புகள்” என்ன திட்டத்தை ஆரம்பத்தில் சில வரையறைகளை அமைக்க வேண்டும்.

  • “இது JS இல்லாமல் செயல்படுகிறது” & mdash; திரையில் உள்ளடக்கத்தை சுமைகள் மற்றும் எதிர்காலத்தில் JS இல்லாமல் வேலை எல்லாம் ஒரு தெளிவான பாதை உள்ளது (அல்லது அது செயல்படுத்தப்படவில்லை ஏன் ஒரு தெளிவான நியாயம் உள்ளது). நான் “என்” என்று சொல்ல முடியாது.
  • “ஒரு சேவைத் தொழிலாளிக்கு எந்த ஆதரவும் இல்லாதபோது இது வேலை செய்கிறது” & mdash; எல்லாம் ஏற்ற வேண்டும், செயல்பட வேண்டும் மற்றும் அதிசயமாக வேகமாக ஆனால் அது எல்லா இடங்களிலும் ஆஃப்லைனில் வேலை இல்லை என்றால் நான் மகிழ்ச்சியாக இருக்கிறேன்.

ஆனால், ஜெயாவும் சேவை ஊழியருக்கான ஆதரவும் இருந்தால், நான் உறுதி செய்ய ஒரு உத்தரவு இருந்தது,

  • அது உடனடியாக ஏற்றப்பட்டது
  • இது நம்பகமானதாக இருந்தது மற்றும் கணிக்கக்கூடிய செயல்திறன் சிறப்பியல்புகளைக் கொண்டது
  • அது முழுமையாக ஆஃப்லைனில் வேலை செய்தது

எனக்கு culpa: நீங்கள் குறியீடு பார்த்து நீங்கள் ஒரு பழைய உலாவியில் அதை ரன் என்றால் அது வேலை செய்யாது ஒரு வலுவான வாய்ப்பு உள்ளது, நான் ES6 பயன்படுத்த தேர்வு, எனினும் இது ஒரு தீர்க்க முடியாத தடை இல்லை.

ஜாவாஸ்கிரிப்ட் இல்லாமல் செயல்படாத ஒரு அனுபவத்தை உருவாக்க நாங்கள் கவனம் செலுத்தினால், அது சர்வரில் நாம் முடிந்த அளவுக்கு வழங்க வேண்டும்.

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

முதலில் என்ன வந்தது. சேவையகம் அல்லது சேவை ஊழியர்?

இது இருவருக்கும் ஒரே நேரத்தில் இருந்தது. நான் சேவையகத்திலிருந்து வழங்க வேண்டும், ஆனால் சேவை ஊழியர் உலாவியிலும் நெட்வொர்க்குக்கும் இடையில் உட்கார்ந்திருப்பதால், நான் இரண்டு முறை எப்படி பேசினேன் என்று சிந்திக்க வேண்டியிருந்தது.

நான் ஒரு அதிர்ஷ்டமான நிலையில் இருந்தேன் நான் தனிப்பட்ட சர்வர் தர்க்கம் நிறைய இல்லை அதனால் நான் ஒரே நேரத்தில் சிக்கலான மற்றும் இரண்டு பிரச்சனை சமாளிக்க முடியும். நான் தொடர்ந்து வந்த கொள்கைகள், முதல் பக்கத்தை (ஒவ்வொரு பயனருக்கும் கிடைக்கும் அனுபவம்) மற்றும் பக்கத்தின் வழங்கல் (பயனர்களை ஈடுபடுத்திய அனுபவம் கிடைக்கும்) ஆகிய இரண்டையும் வழங்குவதன் மூலம் நான் எதை விரும்பினேன் என்று சிந்திக்க வேண்டும் சேவை ஊழியர்.

** முதலில் வழங்குவது ** & mdash; சேவை ஊழியர் கிடைக்காததால், முதல் உள்ளடக்கத்தை முடிந்தவரை உள்ளடக்கத்தை உள்ளடக்கியது மற்றும் சர்வரில் அதை உருவாக்கியிருப்பதை நான் உறுதிசெய்தேன்.

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

Feed டெக் - முதல் சுமை

** சேவை ஊழியர் இல்லாமல் இரண்டாவது வழங்கல் ** & mdash; இது ஒரு முதல் ரெண்டரை போலவே செயல்பட வேண்டும். இயல்பான HTTP கேச்சிங்கில் இருந்து நாம் பயனடையலாம், ஆனால் கோட்பாடு அதேதான்: விரைவான அனுபவத்தை அளிக்கவும்.

** இரண்டாவது வழங்கல் with சேவை ஊழியர் ** & mdash; இது * முதல் சேவையகம் வழங்குவது போல * சரியாக செயல்பட வேண்டும், ஆனால், அனைத்து சேவை ஊழியர்களிடமும். எனக்கு பாரம்பரிய ஷெல் இல்லை. நீங்கள் பார்க்கும் பிணையத்தை நீங்கள் பார்த்தால், முழுமையாக ஒன்றாக இணைக்கப்பட்டுள்ள HTML: கட்டமைப்பு and உள்ளடக்கம்.

“வழங்கல்” & mdash; ஸ்ட்ரீமிங் எங்கள் நண்பர்

நான் முடிந்தவரை முற்போக்கானவராக இருக்க முயற்சிக்கிறேன், அதாவது சர்வரில் முடிந்தவரை விரைவாகச் செய்ய வேண்டும் என்று அர்த்தம். நான் எல்லா RSS செய்திகளிலிருந்தும் எல்லா தரவையும் இணைத்திருந்தால் முதல் சோதனையானது RSS ஊட்டங்களுக்கு நெட்வொர்க் கோரிக்கைகளால் தடுக்கப்பட்டிருக்கும், எனவே நாங்கள் முதலில் வழங்கியதை மெதுவாக்குவோம்.

நான் பின்வரும் பாதையைத் தேர்ந்தெடுத்தேன்:

பக்கத்தின் தலைவரை & mdash; இது ஒப்பீட்டளவில் நிலையானது, இது விரைவாக செயல்திறன் கொண்ட செயல்திட்டத்துடன் திரையில் விரைவாக உதவுகிறது. * கட்டமைப்பு (பத்திகள்) & mdash அடிப்படையிலான பக்கத்தின் கட்டமைப்பை வழங்கவும் கொடுக்கப்பட்ட பயனருக்கு இது தற்போது நிலையானது மற்றும் பயனர்களுக்கு இது விரைவாகத் தெரியும். * நெடுவரிசை தரவுகளை அனுப்புக *** உள்ளடக்கம் இருந்தால், நாங்கள் உள்ளடக்கத்தை தற்காலிக சேமிப்பில் வைத்திருப்போம், இது சேவையகத்திலும் சேவை ஊழியரிடத்திலும் செய்ய முடியும் * அவ்வப்போது பக்கத்தின் உள்ளடக்கங்களை புதுப்பிப்பதற்கான தர்க்கத்தை கொண்டிருக்கும் பக்கத்தின் அடிக்குறிப்பை வழங்கவும்.

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

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

நெடுவரிசை தரவுகளை (அதாவது, ஊட்டத்தில் இருந்ததை) ரெண்டரிங் செய்வது மிகவும் முக்கியமானது மற்றும் இது நேரத்தில், முதல் சுமைக்கு வாடிக்கையாளருக்கு JavaScript தேவைப்படுகிறது. கணினி முதல் சுமைக்கு சர்வரில் எல்லாவற்றையும் வழங்க முடியும், ஆனால் நெட்வொர்க்கில் தடுக்க நான் தேர்வு செய்யவில்லை.

தரவு ஏற்கெனவே கிடைத்திருந்தால், அது சேவையக ஊழியரிலிருந்தே கிடைத்தால், விரைவாக பயனளிக்க முடியாவிட்டாலும், விரைவில் பயனரிடம் இதைப் பெறலாம்.

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

சேவையகத்தில் மற்றும் சேவையக ஊழியர்களில் நான் பயன்படுத்தும் குறியீட்டிற்கு கீழே உள்ளேன்.

const root = (dataPath, assetPath) => {
  
  let columnData = loadData(`${dataPath}columns.json`).then(r => r.json());

  let headTemplate = getCompiledTemplate(`${assetPath}templates/head.html`);
  let bodyTemplate = getCompiledTemplate(`${assetPath}templates/body.html`);
  let itemTemplate = getCompiledTemplate(`${assetPath}templates/item.html`);
  
  let jsonFeedData = fetchCachedFeedData(columnData, itemTemplate);
  
  /*
   * Render the head from the cache or network
   * Render the body.
     * Body has template that brings in config to work out what to render
     * If we have data cached let's bring that in.
   * Render the footer - contains JS to data bind client request.
  */
  
  const headStream = headTemplate.then(render => render({ columns: columnData }));
  const bodyStream = jsonFeedData.then(columns => bodyTemplate.then(render => render({ columns: columns })));
  const footStream = loadTemplate(`${assetPath}templates/foot.html`);

  let concatStream = new ConcatStream;
  
  headStream.then(stream => stream.pipeTo(concatStream.writable, { preventClose:true }))
                .then(() => bodyStream)
                .then(stream => stream.pipeTo(concatStream.writable, { preventClose: true }))
                .then(() => footStream)
                .then(stream => stream.pipeTo(concatStream.writable));
  
  return Promise.resolve(new Response(concatStream.readable, { status: "200" }))
}

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

ஒருங்கிணைந்த தர்க்கம் சேவையகம் மற்றும் சேவை ஊழியர் தர்க்கம் & mdash; வளையங்களும் தடைகளும்

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

நான் திட்டம் முழுவதும் வலை விரும்புகிறேன் தேர்வு. ஏபிஐ இருந்தது என்றால், நான் சர்வர் (நான் இதை அளவிட முடியாது, பயனர் முடியாது), அந்த சர்வர் மீது வெற்றி பெற முடியும் பயனர் கட்டுப்பாட்டு குறியீட்டு சுமை மற்றும் சுமை விரும்பவில்லை, ஏனெனில் நான் இந்த மீது decied ‘ t இல் துணைபுரிந்த பின் நான் இணக்கமான shim ஐக் கண்டுபிடிக்க வேண்டும்.

நான் எதிர்கொண்ட சில சவால்கள் இங்கே.

ஒரு உடைந்த தொகுதி முறைமை

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

நான் உலாவியில் CommonJS ஐ விரும்பவில்லை. நான் முடிந்தவரை அதிக கருவி கருவூட்டல் இருந்து விலகி இருக்க ஒரு பகுத்தறிவு ஆசை மற்றும் எப்படி bundling படைப்புகளை என் வெறுப்பு சேர்க்க, அது எனக்கு நிறைய விருப்பங்களை விட்டு.

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

** sw.js **

importScripts(`/scripts/router.js`);
importScripts(`/scripts/dot.js`);
importScripts(`/scripts/platform/web.js`);
importScripts(`/scripts/platform/common.js`);
importScripts(`/scripts/routes/index.js`);
importScripts(`/scripts/routes/root.js`);
importScripts(`/scripts/routes/proxy.js`);

பின்னர் முனையிலும், அதே கோப்பில் பொதுவான CommonJS ஏற்றுதல் பொறிமுறையைப் பயன்படுத்தினேன், ஆனால் அவை தொகுதிகள் இறக்குமதி செய்ய ஒரு எளிய if அறிக்கையின் பின்னால் அணிவகுத்து நிற்கின்றன.

if (typeof module !== 'undefined' && module.exports) {
    var doT = require('../dot.js');
    ...

என் தீர்வு ஒரு தக்க தீர்வு இல்லை, அது வேலை ஆனால் என் குறியீடு சிதறி, நான் விரும்பவில்லை என்று நன்கு குறியீடு.

நான் உலாவிகளை ஆதரிக்கும் நூல்` தொகுதிகளை ஆதரிக்கும் நாளுக்கு முன்னோக்கி எதிர்நோக்குகிறேன் … எங்களுக்கு எளிய, புத்திசாலி, பகிரப்பட்ட மற்றும் மேம்பட்ட ஒன்று தேவை.

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

கடக்கும் நீரோடைகள்

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

அதிர்ஷ்டவசமாக நீங்கள் ஸ்ட்ரீம் API - (Node Stream மற்றும் Node Stream -> Web Stream -> Node Stream மற்றும் Node Stream -> வலை இருந்து வரைபடத்தை ஒரு ஜோடி எழுதுங்கள், நீங்கள் Node கொண்டு வர முடியும் Streams ஏபி ஒரு முழு செயல்படுத்த உள்ளது ஸ்ட்ரீம்.

const nodeReadStreamToWHATWGReadableStream = (stream) => {
    
  return new ReadableStream({
    start(controller) {
      stream.on('data', data => {
        controller.enqueue(data)
      });
      stream.on('error', (error) => controller.abort(error))
      stream.on('end', () => {
        controller.close();
      })
    }
  });
};

class FromWHATWGReadableStream extends Readable {
  constructor(options, whatwgStream) {
    super(options);
    const streamReader = whatwgStream.getReader();
    
    pump(this);

    function pump(outStream) {
      return streamReader.read().then(({ value, done }) => {
        if (done) {
          outStream.push(null);
          return;
        }

        outStream.push(value.toString());
        return pump(outStream);
      });
    }
  }
}

இந்த இரண்டு உதவி செயல்பாடுகளை மட்டுமே இந்த திட்டத்தின் முனை பக்கத்தில் பயன்படுத்தப்பட்டது மற்றும் அவர்கள் என்ட் ஏபிஎஸ் தான் தரவு பெற அனுமதிக்க பயன்படுத்தப்படும் என்று WHATWG ஸ்ட்ரீம்ஸ் ஏற்றுக்கொள்ள மற்றும் அதேபோல் Node Streams புரிந்து கொள்ளாத WHATWG ஸ்ட்ரீம் இணக்கமான API கள் தரவு அனுப்ப . நான் குறிப்பாக இந்த நோட் ‘கிடைக்கும்’ API க்கு தேவை.

ஒருமுறை ஸ்ட்ரீம்ஸ் வரிசைப்படுத்தப்பட்டபோது, ​​இறுதிப் பிரச்சனை மற்றும் சீரற்ற தன்மை இரட்டிப்பாக இருந்தது (தற்செயலாக இதுதான் நான் ஸ்ட்ரீம் மிக அதிகமாக உபயோகப்படுத்தியது).

பகிரப்பட்ட ரூட்டிங்

நோட் சுற்றுச்சூழல், குறிப்பாக எக்ஸ்பிரஸ் நம்பமுடியாத அளவிற்கு நன்கு அறியப்பட்ட மற்றும் அதிசயமாக வலுவானதாக உள்ளது, ஆனால் வாடிக்கையாளர் மற்றும் சேவை ஊழியர்களிடையே பகிர்வு மாதிரி இல்லை.

ஆண்டுகளுக்கு முன்பு நான் LeviRoutes எழுதியது, ஒரு எளிய உலாவி பக்க நூலகம் ExpressJS பாதைகளைப் போன்றது மற்றும் History API இல் இணையும் மற்றும் onhashchange API இல் இணையும். யாரும் அதை பயன்படுத்தவில்லை ஆனால் நான் மகிழ்ச்சியாக இருந்தேன். நான் cobwebs தூசி நிர்வகிக்கப்படும் (ஒரு மாற்றங்களை அல்லது இரண்டு செய்ய) இந்த பயன்பாட்டை அதை பயன்படுத்த. நீங்கள் கீழேயுள்ள குறியீட்டைப் பார்க்கும்போது, ​​என் ரூட்டிங் என்பது nearly அதே போல உள்ளது.

** server.js **

app.get('/', (req, res, next) => {
  routes['root'](dataPath, assetPath)
    .then(response => node.responseToExpressStream(res, response));         
});

app.get('/proxy', (req, res, next) => {
  routes['proxy'](dataPath, assetPath, req)
    .then(response => response.body.pipe(res, {end: true}));
})

** sw.js **

// The proxy server '/proxy'
router.get(`${self.location.origin}/proxy`, (e) => {
  e.respondWith(routes['proxy'](dataPath, assetPath, e.request));
}, {urlMatchProperty: 'href'});

// The root '/'
router.get(`${self.location.origin}/$`, (e) => {
  e.respondWith(routes['root'](dataPath, assetPath));
}, {urlMatchProperty: 'href'});

சேவை ஊழியர் onfetch API ஐ node க்கு கொண்டு வரும் ஒரு ஒருங்கிணைந்த தீர்வைப் பார்க்க நான் love வேண்டும்.

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

விட DOM விடாது

பயனர் சேவை ஊழியர் இல்லாத போது, ​​தளத்திற்கான தர்க்கம் மிகவும் பாரம்பரியமானது, சேவையகத்தில் தளத்தை வழங்குவதோடு, பாரம்பரிய அஜாக்ஸ் வாக்குப்பதிவின் மூலம் பக்கத்தின் உள்ளடக்கத்தை அதிகரிக்கவும்.

தர்க்கம் ஒரு DOMPARSER API ஐ பயன்படுத்துகிறது, ஒரு RSS feed ஐ பக்கத்திற்கு வடிகட்டவும் வினவலுக்கும் மாற்றலாம்.

// Get the RSS feed data.
fetch(`/proxy?url=${feedUrl}`)
      .then(feedResponse => feedResponse.text())
      // Convert it in to DOM
      .then(feedText => {
        const parser = new DOMParser();
        return parser.parseFromString(feedText,'application/xml');
      })
      // Find all the news items
      .then(doc => doc.querySelectorAll('item'))
      // Convert to an array
      .then(items => Array.prototype.map.call(items, item => convertRSSItemToJSON(item)))
      // Don't add in items that already exist in the page
      .then(items => items.filter(item => !!!(document.getElementById(item.guid))))
      // DOM Template.
      .then(items => items.map(item => applyTemplate(itemTemplate.cloneNode(true), item)))
      // Add it into the page
      .then(items => items.forEach(item => column.appendChild(item)))

உலாவியில் நிலையான API களைப் பயன்படுத்தி ஆர்எஸ்எஸ் பயன்பாட்டின் DOM ஐ அணுகுவது நம்பமுடியாத பயனுள்ளது மற்றும் பக்கத்தை மாற்றியமைக்க என் சொந்த மாதிரியாக்கம் (நான் மிகவும் பெருமைப்படுகிறேன்) பயன்படுத்துவதை அனுமதித்தது.

<template id='itemTemplate'>
  <div class="item" data-bind_id='guid'>
    <h3><span data-bind_inner-text='title'></span> (<a data-bind_href='link'>#</a>)</h3>
    <div data-bind_inner-text='pubDate'></div>
  </div>
</template>
<script>
  
const applyTemplate = (templateElement, data) => {
  const element = templateElement.content.cloneNode(true);    
  const treeWalker = document.createTreeWalker(element, NodeFilter.SHOW_ELEMENT, () => NodeFilter.FILTER_ACCEPT);

  while(treeWalker.nextNode()) {
    const node = treeWalker.currentNode;
    for(let bindAttr in node.dataset) {
      let isBindableAttr = (bindAttr.indexOf('bind_') == 0) ? true : false;
      if(isBindableAttr) {
        let dataKey = node.dataset[bindAttr];
        let bindKey = bindAttr.substr(5);
        node[bindKey] = data[dataKey];
      }
    }
  }

  return element;
};
</script>

நான் சர்வரில் அல்லது சேவையக ஊழியர்களில் இதைப் பயன்படுத்த முடியாது என்பதை உணர்ந்த வரை என்னால் மிகவும் மகிழ்ச்சி அடைந்தேன். நான் ஒரு தனிபயன் எக்ஸ்எம்எல் பாகுபடுத்தி இல் கொண்டு வந்தேன் மற்றும் HTML ஐ உருவாக்குவது என்று நடந்து கொண்டேன். அது சில சிக்கல்களைச் சேர்த்ததுடன், இணையத்தை சபித்தேன்.

நீண்ட காலமாக DOM API இன் சில இன்னும் தொழிலாளர்கள் மீது கொண்டுவருவதை விரும்புகிறேன், மேலும் இது Node இல் துணைபுரிகிறது, ஆனால் நான் உகந்ததாக இல்லாதபோதும் வேலை செய்யும் தீர்வு.

இது முடியுமா?

இந்த இடுகையில் உண்மையில் இரண்டு கேள்விகள் உள்ளன:

  • ஒரு பொதுவான சேவையகம் மற்றும் சேவையக ஊழியர்களை அமைப்புகளை உருவாக்குவது நடைமுறையானதா?
  • ஒரு முழுமையான முற்போக்கான வலை பயன்பாட்டை உருவாக்க முடியுமா?

ஒரு பொதுவான சேவையகம் மற்றும் சேவையக ஊழியரை கணினிகளை உருவாக்குவது நடைமுறைப்படுத்துமா?

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

தனிப்பட்ட முறையில் நான் நோட் சுற்றுச்சூழலில் மேலும் “வலை” API களைப் பார்க்க விரும்புகிறேன்.

ஒரு முழுமையான முற்போக்கான வலை பயன்பாட்டை உருவாக்க முடியுமா?

ஆம்.

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

  1. AppShell நீங்கள் பின்பற்ற முடியும் என்று மட்டும் மாதிரி அல்ல, முக்கிய புள்ளி சேவை ஊழியர் you நெட்வொர்க் கட்டுப்பாட்டை பெற மற்றும் you உங்கள் பயன்பாடு வழக்கு சிறந்த என்ன முடிவு செய்ய முடியும். 2. செயல்திறன் மற்றும் பின்னடைவு (அதே போல் ஒரு நிறுவப்பட்ட உணர்வு நீங்கள் விரும்பினால்) கொண்டு சேவை தொழிலாளி பயன்படுத்தும் ஒரு படிப்படியாக அளிக்கப்பட்ட அனுபவம் உருவாக்க முடியும். நீங்கள் முழுமையாக சிந்திக்க வேண்டும், முதலில் சர்வரில் நீங்கள் எவ்வளவு முடியுமோ அவ்வளவு சீக்கிரம் தொடங்க வேண்டும், பின்னர் வாடிக்கையாளர் கட்டுப்பாட்டை எடுத்துக்கொள்ள வேண்டும். 3. ஒரு பொதுவான குறியீடு அடிப்படை, ஒரு பொது ரூட்டிங் அமைப்பு மற்றும் வாடிக்கையாளர், சேவை தொழிலாளி மற்றும் சேவையகம் முழுவதும் பகிர்ந்து பொதுவான தர்க்கம் கொண்டு “trisomorphically” (நான் இன்னும் கால சமன்பாடு சிறந்த நினைக்கிறேன்) கட்டப்பட்டது என்று அனுபவங்களை பற்றி யோசிக்க முடியும்.

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

நீங்கள் குறியீட்டில் ஆர்வமாக இருந்தால், Github ஐப் பாருங்கள் ஆனால் நீங்கள் அதனுடன் விளையாடலாம் நேரடியாகவும், அதை மறுபிரதி எடுக்கவும்

Paul Kinlan

Trying to make the web and developers better.

RSS Github Medium