ਹੈਬਰ ਫਰੰਟ-ਐਂਡ ਡਿਵੈਲਪਰ ਲੌਗਸ: ਰੀਫੈਕਟਰਿੰਗ ਅਤੇ ਰਿਫਲੈਕਟਿੰਗ

ਮੈਂ ਹਮੇਸ਼ਾਂ ਇਸ ਗੱਲ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹਾਂ ਕਿ ਹੈਬਰ ਨੂੰ ਅੰਦਰੋਂ ਕਿਵੇਂ ਬਣਾਇਆ ਗਿਆ ਹੈ, ਵਰਕਫਲੋ ਕਿਵੇਂ ਸੰਰਚਨਾ ਕੀਤੀ ਗਈ ਹੈ, ਸੰਚਾਰ ਕਿਵੇਂ ਬਣਤਰ ਕੀਤੇ ਗਏ ਹਨ, ਕਿਹੜੇ ਮਾਪਦੰਡ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕੋਡ ਆਮ ਤੌਰ 'ਤੇ ਇੱਥੇ ਕਿਵੇਂ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ। ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਮੈਨੂੰ ਅਜਿਹਾ ਮੌਕਾ ਮਿਲਿਆ, ਕਿਉਂਕਿ ਮੈਂ ਹਾਲ ਹੀ ਵਿੱਚ ਹਾਬਰਾ ਟੀਮ ਦਾ ਹਿੱਸਾ ਬਣਿਆ ਹਾਂ। ਮੋਬਾਈਲ ਸੰਸਕਰਣ ਦੀ ਇੱਕ ਛੋਟੀ ਜਿਹੀ ਰੀਫੈਕਟਰਿੰਗ ਦੀ ਉਦਾਹਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਮੈਂ ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ: ਇੱਥੇ ਅੱਗੇ ਕੰਮ ਕਰਨਾ ਕੀ ਹੈ. ਪ੍ਰੋਗਰਾਮ ਵਿੱਚ: ਹੈਬਰ ਵਿੱਚ ਨਿੱਜੀ ਅਨੁਭਵ ਬਾਰੇ ਨੋਟਸ ਤੋਂ ਸਾਸ ਦੇ ਨਾਲ ਨੋਡ, ਵਯੂ, ਵਯੂਐਕਸ ਅਤੇ ਐਸਐਸਆਰ.

ਵਿਕਾਸ ਟੀਮ ਬਾਰੇ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਸਾਡੇ ਵਿੱਚੋਂ ਕੁਝ ਹੀ ਹਨ। ਕਾਫ਼ੀ ਨਹੀਂ - ਇਹ ਤਿੰਨ ਮੋਰਚੇ, ਦੋ ਪਿੱਠਾਂ ਅਤੇ ਸਾਰੇ ਹੈਬਰ ਦੀ ਤਕਨੀਕੀ ਲੀਡ ਹਨ - ਬੈਕਸਲੇ. ਬੇਸ਼ੱਕ, ਇੱਕ ਟੈਸਟਰ, ਇੱਕ ਡਿਜ਼ਾਇਨਰ, ਤਿੰਨ ਵਦੀਮ, ਇੱਕ ਚਮਤਕਾਰ ਝਾੜੂ, ਇੱਕ ਮਾਰਕੀਟਿੰਗ ਮਾਹਰ ਅਤੇ ਹੋਰ ਬੰਬੂਰਮ ਵੀ ਹਨ. ਪਰ ਹੈਬਰ ਦੇ ਸਰੋਤਾਂ ਵਿੱਚ ਸਿਰਫ ਛੇ ਸਿੱਧੇ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲੇ ਹਨ। ਇਹ ਬਹੁਤ ਦੁਰਲੱਭ ਹੈ - ਮਲਟੀਮਿਲੀਅਨ-ਡਾਲਰ ਸਰੋਤਿਆਂ ਵਾਲਾ ਇੱਕ ਪ੍ਰੋਜੈਕਟ, ਜੋ ਬਾਹਰੋਂ ਇੱਕ ਵਿਸ਼ਾਲ ਉੱਦਮ ਵਰਗਾ ਲੱਗਦਾ ਹੈ, ਅਸਲ ਵਿੱਚ ਸਭ ਤੋਂ ਫਲੈਟ ਸੰਸਥਾਗਤ ਢਾਂਚੇ ਦੇ ਨਾਲ ਇੱਕ ਆਰਾਮਦਾਇਕ ਸ਼ੁਰੂਆਤ ਵਰਗਾ ਲੱਗਦਾ ਹੈ।

ਹੋਰ ਬਹੁਤ ਸਾਰੀਆਂ ਆਈਟੀ ਕੰਪਨੀਆਂ ਦੀ ਤਰ੍ਹਾਂ, ਹੈਬਰ ਚੁਸਤ ਵਿਚਾਰਾਂ, ਸੀਆਈ ਅਭਿਆਸਾਂ, ਅਤੇ ਇਹ ਸਭ ਕੁਝ ਹੈ. ਪਰ ਮੇਰੀਆਂ ਭਾਵਨਾਵਾਂ ਦੇ ਅਨੁਸਾਰ, ਹਾਬਰ ਇੱਕ ਉਤਪਾਦ ਦੇ ਰੂਪ ਵਿੱਚ ਲਗਾਤਾਰ ਵੱਧ ਤਰੰਗਾਂ ਵਿੱਚ ਵੱਧ ਰਿਹਾ ਹੈ। ਇਸ ਲਈ, ਇੱਕ ਕਤਾਰ ਵਿੱਚ ਕਈ ਸਪ੍ਰਿੰਟਸ ਲਈ, ਅਸੀਂ ਲਗਨ ਨਾਲ ਕੁਝ ਕੋਡ ਕਰਦੇ ਹਾਂ, ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹਾਂ ਅਤੇ ਦੁਬਾਰਾ ਡਿਜ਼ਾਈਨ ਕਰਦੇ ਹਾਂ, ਕੁਝ ਤੋੜਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਠੀਕ ਕਰਦੇ ਹਾਂ, ਟਿਕਟਾਂ ਦਾ ਹੱਲ ਕਰਦੇ ਹਾਂ ਅਤੇ ਨਵੇਂ ਬਣਾਉਂਦੇ ਹਾਂ, ਇੱਕ ਰੈਕ 'ਤੇ ਕਦਮ ਰੱਖਦੇ ਹਾਂ ਅਤੇ ਆਪਣੇ ਆਪ ਨੂੰ ਪੈਰਾਂ ਵਿੱਚ ਮਾਰਦੇ ਹਾਂ, ਅੰਤ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਜਾਰੀ ਕਰਨ ਲਈ। ਉਤਪਾਦਨ. ਅਤੇ ਫਿਰ ਇੱਕ ਨਿਸ਼ਚਤ ਸ਼ਾਂਤ, ਪੁਨਰ ਵਿਕਾਸ ਦੀ ਮਿਆਦ, ਉਹ ਕਰਨ ਦਾ ਸਮਾਂ ਆਉਂਦਾ ਹੈ ਜੋ "ਮਹੱਤਵਪੂਰਨ-ਜ਼ਰੂਰੀ ਨਹੀਂ" ਚੌਥਾਈ ਵਿੱਚ ਹੈ।

ਇਹ ਬਿਲਕੁਲ ਇਹ "ਆਫ-ਸੀਜ਼ਨ" ਸਪ੍ਰਿੰਟ ਹੈ ਜਿਸ ਬਾਰੇ ਹੇਠਾਂ ਚਰਚਾ ਕੀਤੀ ਜਾਵੇਗੀ। ਇਸ ਵਾਰ ਇਸ ਵਿੱਚ ਹੈਬਰ ਦੇ ਮੋਬਾਈਲ ਸੰਸਕਰਣ ਦੀ ਇੱਕ ਰੀਫੈਕਟਰਿੰਗ ਸ਼ਾਮਲ ਹੈ। ਆਮ ਤੌਰ 'ਤੇ, ਕੰਪਨੀ ਨੂੰ ਇਸਦੇ ਲਈ ਬਹੁਤ ਉਮੀਦਾਂ ਹਨ, ਅਤੇ ਭਵਿੱਖ ਵਿੱਚ ਇਸਨੂੰ ਹੈਬਰ ਦੇ ਅਵਤਾਰਾਂ ਦੇ ਪੂਰੇ ਚਿੜੀਆਘਰ ਨੂੰ ਬਦਲਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਇੱਕ ਸਰਵ ਵਿਆਪਕ ਕਰਾਸ-ਪਲੇਟਫਾਰਮ ਹੱਲ ਬਣਨਾ ਚਾਹੀਦਾ ਹੈ। ਕਿਸੇ ਦਿਨ ਅਨੁਕੂਲ ਲੇਆਉਟ, PWA, ਔਫਲਾਈਨ ਮੋਡ, ਉਪਭੋਗਤਾ ਅਨੁਕੂਲਤਾ ਅਤੇ ਹੋਰ ਬਹੁਤ ਸਾਰੀਆਂ ਦਿਲਚਸਪ ਚੀਜ਼ਾਂ ਹੋਣਗੀਆਂ।

ਚਲੋ ਟਾਸਕ ਸੈੱਟ ਕਰੀਏ

ਇੱਕ ਵਾਰ, ਇੱਕ ਸਧਾਰਣ ਸਟੈਂਡ-ਅੱਪ 'ਤੇ, ਇੱਕ ਫਰੰਟ ਨੇ ਮੋਬਾਈਲ ਸੰਸਕਰਣ ਦੇ ਟਿੱਪਣੀਆਂ ਦੇ ਹਿੱਸੇ ਦੇ ਢਾਂਚੇ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਬਾਰੇ ਗੱਲ ਕੀਤੀ. ਇਸ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਅਸੀਂ ਸਮੂਹ ਮਨੋ-ਚਿਕਿਤਸਾ ਦੇ ਫਾਰਮੈਟ ਵਿੱਚ ਇੱਕ ਮਾਈਕ੍ਰੋ-ਮੀਟਿੰਗ ਦਾ ਆਯੋਜਨ ਕੀਤਾ। ਹਰ ਕੋਈ ਵਾਰੀ-ਵਾਰੀ ਕਹਿੰਦਾ ਕਿ ਕਿੱਥੇ ਦੁੱਖ ਹੋਇਆ, ਉਨ੍ਹਾਂ ਨੇ ਸਭ ਕੁਝ ਕਾਗਜ਼ 'ਤੇ ਦਰਜ ਕੀਤਾ, ਉਨ੍ਹਾਂ ਨੇ ਹਮਦਰਦੀ ਕੀਤੀ, ਉਹ ਸਮਝ ਗਏ, ਸਿਵਾਏ ਕਿਸੇ ਨੇ ਤਾੜੀ ਨਹੀਂ ਵਜਾਈ। ਨਤੀਜਾ 20 ਸਮੱਸਿਆਵਾਂ ਦੀ ਸੂਚੀ ਸੀ, ਜਿਸ ਨੇ ਇਹ ਸਪੱਸ਼ਟ ਕੀਤਾ ਕਿ ਮੋਬਾਈਲ ਹੈਬਰ ਕੋਲ ਅਜੇ ਵੀ ਸਫਲਤਾ ਦਾ ਇੱਕ ਲੰਮਾ ਅਤੇ ਕੰਡੇ ਵਾਲਾ ਰਸਤਾ ਹੈ।

ਮੈਂ ਮੁੱਖ ਤੌਰ 'ਤੇ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਦੀ ਕੁਸ਼ਲਤਾ ਬਾਰੇ ਚਿੰਤਤ ਸੀ ਅਤੇ ਜਿਸਨੂੰ ਇੱਕ ਨਿਰਵਿਘਨ ਇੰਟਰਫੇਸ ਕਿਹਾ ਜਾਂਦਾ ਹੈ. ਹਰ ਰੋਜ਼, ਹੋਮ-ਵਰਕ-ਹੋਮ ਰੂਟ 'ਤੇ, ਮੈਂ ਦੇਖਿਆ ਕਿ ਮੇਰਾ ਪੁਰਾਣਾ ਫ਼ੋਨ ਫੀਡ ਵਿੱਚ 20 ਸੁਰਖੀਆਂ ਦਿਖਾਉਣ ਦੀ ਸਖ਼ਤ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਿਹਾ ਹੈ। ਇਹ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ:

ਰੀਫੈਕਟਰਿੰਗ ਤੋਂ ਪਹਿਲਾਂ ਮੋਬਾਈਲ ਹੈਬਰ ਇੰਟਰਫੇਸ

ਇੱਥੇ ਕੀ ਹੋ ਰਿਹਾ ਹੈ? ਸੰਖੇਪ ਰੂਪ ਵਿੱਚ, ਸਰਵਰ ਨੇ HTML ਪੰਨੇ ਨੂੰ ਹਰ ਕਿਸੇ ਨੂੰ ਉਸੇ ਤਰੀਕੇ ਨਾਲ ਸੇਵਾ ਦਿੱਤੀ, ਭਾਵੇਂ ਉਪਭੋਗਤਾ ਲੌਗਇਨ ਹੋਇਆ ਸੀ ਜਾਂ ਨਹੀਂ। ਫਿਰ ਕਲਾਇੰਟ JS ਲੋਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਲੋੜੀਂਦੇ ਡੇਟਾ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ, ਪਰ ਅਧਿਕਾਰ ਲਈ ਐਡਜਸਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਭਾਵ, ਅਸੀਂ ਅਸਲ ਵਿੱਚ ਇੱਕੋ ਕੰਮ ਦੋ ਵਾਰ ਕੀਤਾ ਹੈ। ਇੰਟਰਫੇਸ ਫਲਿੱਕਰ ਹੋ ਗਿਆ, ਅਤੇ ਉਪਭੋਗਤਾ ਨੇ ਇੱਕ ਚੰਗੇ ਸੌ ਵਾਧੂ ਕਿਲੋਬਾਈਟ ਡਾਊਨਲੋਡ ਕੀਤੇ। ਵਿਸਤਾਰ ਵਿੱਚ ਸਭ ਕੁਝ ਹੋਰ ਵੀ ਡਰਾਉਣਾ ਲੱਗ ਰਿਹਾ ਸੀ।

ਪੁਰਾਣੀ SSR-CSR ਸਕੀਮ। ਅਧਿਕਾਰ ਸਿਰਫ਼ C3 ਅਤੇ C4 ਪੜਾਵਾਂ 'ਤੇ ਹੀ ਸੰਭਵ ਹੈ, ਜਦੋਂ ਨੋਡ ਜੇਐਸ HTML ਬਣਾਉਣ ਵਿੱਚ ਰੁੱਝਿਆ ਨਹੀਂ ਹੁੰਦਾ ਹੈ ਅਤੇ API ਨੂੰ ਪ੍ਰੌਕਸੀ ਬੇਨਤੀਆਂ ਕਰ ਸਕਦਾ ਹੈ।

ਉਸ ਸਮੇਂ ਦੀ ਸਾਡੀ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਹੈਬਰ ਉਪਭੋਗਤਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੁਆਰਾ ਬਹੁਤ ਸਹੀ ਢੰਗ ਨਾਲ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਸੀ:

ਮੋਬਾਈਲ ਸੰਸਕਰਣ ਬਕਵਾਸ ਹੈ. ਮੈਂ ਇਸਨੂੰ ਦੱਸ ਰਿਹਾ ਹਾਂ ਜਿਵੇਂ ਇਹ ਹੈ. SSR ਅਤੇ CSR ਦਾ ਇੱਕ ਭਿਆਨਕ ਸੁਮੇਲ.

ਸਾਨੂੰ ਇਹ ਸਵੀਕਾਰ ਕਰਨਾ ਪਿਆ, ਭਾਵੇਂ ਇਹ ਕਿੰਨਾ ਵੀ ਦੁਖੀ ਕਿਉਂ ਨਾ ਹੋਵੇ.

ਮੈਂ ਵਿਕਲਪਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕੀਤਾ, "ਇਹ ਹੁਣ ਬੁਰਾ ਹੈ, ਇਸ ਨੂੰ ਸਹੀ ਕਰੋ" ਦੇ ਪੱਧਰ 'ਤੇ ਵਰਣਨ ਦੇ ਨਾਲ ਜੀਰਾ ਵਿੱਚ ਇੱਕ ਟਿਕਟ ਬਣਾਇਆ ਅਤੇ ਕੰਮ ਨੂੰ ਵਿਆਪਕ ਸਟ੍ਰੋਕ ਵਿੱਚ ਵਿਗਾੜ ਦਿੱਤਾ:

• ਡੇਟਾ ਦੀ ਮੁੜ ਵਰਤੋਂ,
• ਰੀਡਰਾਅ ਦੀ ਗਿਣਤੀ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰੋ,
• ਡੁਪਲੀਕੇਟ ਬੇਨਤੀਆਂ ਨੂੰ ਖਤਮ ਕਰੋ,
• ਲੋਡਿੰਗ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਹੋਰ ਸਪੱਸ਼ਟ ਬਣਾਓ।

ਆਉ ਡੇਟਾ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰੀਏ

ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ, ਸਰਵਰ-ਸਾਈਡ ਰੈਂਡਰਿੰਗ ਨੂੰ ਦੋ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ: ਖੋਜ ਇੰਜਣ ਦੀਆਂ ਸੀਮਾਵਾਂ ਤੋਂ ਪੀੜਤ ਨਾ ਹੋਣਾ SPA ਇੰਡੈਕਸਿੰਗ ਅਤੇ ਮੈਟ੍ਰਿਕ ਵਿੱਚ ਸੁਧਾਰ ਕਰੋ FMP (ਅਵੱਸ਼ਕ ਤੌਰ 'ਤੇ ਵਿਗੜਨਾ ਟੀ.ਟੀ.ਆਈ.). ਇੱਕ ਕਲਾਸਿਕ ਦ੍ਰਿਸ਼ ਵਿੱਚ ਜੋ ਅੰਤ ਵਿੱਚ 2013 ਵਿੱਚ Airbnb 'ਤੇ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ ਸਾਲ (ਅਜੇ ਵੀ Backbone.js 'ਤੇ), SSR ਉਹੀ ਆਈਸੋਮੋਰਫਿਕ JS ਐਪਲੀਕੇਸ਼ਨ ਹੈ ਜੋ ਨੋਡ ਵਾਤਾਵਰਣ ਵਿੱਚ ਚੱਲ ਰਹੀ ਹੈ। ਸਰਵਰ ਸਿਰਫ਼ ਬੇਨਤੀ ਦੇ ਜਵਾਬ ਵਜੋਂ ਤਿਆਰ ਕੀਤੇ ਖਾਕੇ ਨੂੰ ਭੇਜਦਾ ਹੈ। ਫਿਰ ਕਲਾਇੰਟ ਸਾਈਡ 'ਤੇ ਰੀਹਾਈਡਰੇਸ਼ਨ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਫਿਰ ਸਭ ਕੁਝ ਪੰਨਾ ਰੀਲੋਡ ਕੀਤੇ ਬਿਨਾਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਹੈਬਰ ਲਈ, ਜਿਵੇਂ ਕਿ ਟੈਕਸਟ ਸਮੱਗਰੀ ਵਾਲੇ ਹੋਰ ਬਹੁਤ ਸਾਰੇ ਸਰੋਤਾਂ ਲਈ, ਸਰਵਰ ਰੈਂਡਰਿੰਗ ਖੋਜ ਇੰਜਣਾਂ ਨਾਲ ਦੋਸਤਾਨਾ ਸਬੰਧ ਬਣਾਉਣ ਲਈ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਤੱਤ ਹੈ।

ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ ਤਕਨਾਲੋਜੀ ਦੇ ਆਗਮਨ ਤੋਂ ਛੇ ਸਾਲ ਤੋਂ ਵੱਧ ਦਾ ਸਮਾਂ ਬੀਤ ਚੁੱਕਾ ਹੈ, ਅਤੇ ਇਸ ਸਮੇਂ ਦੌਰਾਨ ਸਾਹਮਣੇ ਵਾਲੇ ਸੰਸਾਰ ਵਿੱਚ ਪੁਲ ਦੇ ਹੇਠਾਂ ਬਹੁਤ ਸਾਰਾ ਪਾਣੀ ਵਹਿ ਗਿਆ ਹੈ, ਬਹੁਤ ਸਾਰੇ ਡਿਵੈਲਪਰਾਂ ਲਈ ਇਹ ਵਿਚਾਰ ਅਜੇ ਵੀ ਗੁਪਤਤਾ ਵਿੱਚ ਡੁੱਬਿਆ ਹੋਇਆ ਹੈ. ਅਸੀਂ ਇੱਕ ਪਾਸੇ ਨਹੀਂ ਖੜ੍ਹੇ ਹੋਏ ਅਤੇ ਉਤਪਾਦਨ ਲਈ SSR ਸਮਰਥਨ ਨਾਲ ਇੱਕ Vue ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਰੋਲ ਆਊਟ ਕੀਤਾ, ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਵੇਰਵਾ ਗੁਆ ਦਿੱਤਾ: ਅਸੀਂ ਕਲਾਇੰਟ ਨੂੰ ਸ਼ੁਰੂਆਤੀ ਸਥਿਤੀ ਨਹੀਂ ਭੇਜੀ।

ਕਿਉਂ? ਇਸ ਸਵਾਲ ਦਾ ਕੋਈ ਸਹੀ ਜਵਾਬ ਨਹੀਂ ਹੈ। ਜਾਂ ਤਾਂ ਉਹ ਸਰਵਰ ਤੋਂ ਜਵਾਬ ਦੇ ਆਕਾਰ ਨੂੰ ਵਧਾਉਣਾ ਨਹੀਂ ਚਾਹੁੰਦੇ ਸਨ, ਜਾਂ ਹੋਰ ਆਰਕੀਟੈਕਚਰਲ ਸਮੱਸਿਆਵਾਂ ਦੇ ਝੁੰਡ ਦੇ ਕਾਰਨ, ਜਾਂ ਇਹ ਸਿਰਫ਼ ਬੰਦ ਨਹੀਂ ਹੋਇਆ. ਇੱਕ ਜਾਂ ਕੋਈ ਹੋਰ, ਸਥਿਤੀ ਨੂੰ ਬਾਹਰ ਕੱਢਣਾ ਅਤੇ ਸਰਵਰ ਦੁਆਰਾ ਕੀਤੀ ਗਈ ਹਰ ਚੀਜ਼ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਨਾ ਕਾਫ਼ੀ ਢੁਕਵਾਂ ਅਤੇ ਉਪਯੋਗੀ ਲੱਗਦਾ ਹੈ. ਕੰਮ ਅਸਲ ਵਿੱਚ ਮਾਮੂਲੀ ਹੈ - ਰਾਜ ਨੂੰ ਸਿਰਫ਼ ਟੀਕਾ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਸੰਦਰਭ ਵਿੱਚ, ਅਤੇ Vue ਆਪਣੇ ਆਪ ਇਸਨੂੰ ਇੱਕ ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਦੇ ਰੂਪ ਵਿੱਚ ਤਿਆਰ ਕੀਤੇ ਲੇਆਉਟ ਵਿੱਚ ਜੋੜਦਾ ਹੈ: window.__INITIAL_STATE__.

ਜਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋਈਆਂ ਹਨ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਚੱਕਰਵਾਤੀ ਬਣਤਰਾਂ ਨੂੰ JSON ਵਿੱਚ ਬਦਲਣ ਦੀ ਅਸਮਰੱਥਾ (ਸਰਕੂਲਰ ਹਵਾਲਾ); ਅਜਿਹੇ ਢਾਂਚੇ ਨੂੰ ਉਹਨਾਂ ਦੇ ਫਲੈਟ ਹਮਰੁਤਬਾ ਨਾਲ ਬਦਲ ਕੇ ਹੱਲ ਕੀਤਾ ਗਿਆ ਸੀ।

ਇਸ ਤੋਂ ਇਲਾਵਾ, UGC ਸਮੱਗਰੀ ਨਾਲ ਨਜਿੱਠਣ ਵੇਲੇ, ਤੁਹਾਨੂੰ ਯਾਦ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਡੇਟਾ ਨੂੰ HTML ਇਕਾਈਆਂ ਵਿੱਚ ਬਦਲਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਤਾਂ ਜੋ HTML ਨੂੰ ਤੋੜਿਆ ਨਾ ਜਾਵੇ। ਇਹਨਾਂ ਉਦੇਸ਼ਾਂ ਲਈ ਅਸੀਂ ਵਰਤਦੇ ਹਾਂ he.

ਦੁਬਾਰਾ ਖਿੱਚਣ ਨੂੰ ਘੱਟ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਉਪਰੋਕਤ ਚਿੱਤਰ ਤੋਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇੱਕ ਨੋਡ ਜੇਐਸ ਉਦਾਹਰਣ ਦੋ ਫੰਕਸ਼ਨ ਕਰਦਾ ਹੈ: API ਵਿੱਚ SSR ਅਤੇ “ਪ੍ਰੌਕਸੀ”, ਜਿੱਥੇ ਉਪਭੋਗਤਾ ਅਧਿਕਾਰ ਹੁੰਦਾ ਹੈ। ਇਹ ਸਥਿਤੀ ਸਰਵਰ 'ਤੇ JS ਕੋਡ ਦੇ ਚੱਲਣ ਦੌਰਾਨ ਅਧਿਕਾਰਤ ਕਰਨਾ ਅਸੰਭਵ ਬਣਾਉਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਨੋਡ ਸਿੰਗਲ-ਥ੍ਰੈੱਡਡ ਹੈ, ਅਤੇ SSR ਫੰਕਸ਼ਨ ਸਮਕਾਲੀ ਹੈ। ਭਾਵ, ਸਰਵਰ ਸਿਰਫ਼ ਆਪਣੇ ਆਪ ਨੂੰ ਬੇਨਤੀਆਂ ਨਹੀਂ ਭੇਜ ਸਕਦਾ ਹੈ ਜਦੋਂ ਕਿ ਕਾਲਸਟੈਕ ਕਿਸੇ ਚੀਜ਼ ਵਿੱਚ ਰੁੱਝਿਆ ਹੋਇਆ ਹੈ। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਅਸੀਂ ਰਾਜ ਨੂੰ ਅਪਡੇਟ ਕੀਤਾ ਹੈ, ਪਰ ਇੰਟਰਫੇਸ ਨੇ ਮਰੋੜਨਾ ਬੰਦ ਨਹੀਂ ਕੀਤਾ, ਕਿਉਂਕਿ ਗਾਹਕ ਦੇ ਡੇਟਾ ਨੂੰ ਉਪਭੋਗਤਾ ਸੈਸ਼ਨ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਅਪਡੇਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਸੀ. ਸਾਨੂੰ ਉਪਭੋਗਤਾ ਦੇ ਲੌਗਇਨ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ, ਸ਼ੁਰੂਆਤੀ ਸਥਿਤੀ ਵਿੱਚ ਸਹੀ ਡੇਟਾ ਪਾਉਣ ਲਈ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਿਖਾਉਣ ਦੀ ਲੋੜ ਸੀ।

ਸਮੱਸਿਆ ਦੇ ਸਿਰਫ ਦੋ ਹੱਲ ਸਨ:

• ਕਰਾਸ-ਸਰਵਰ ਬੇਨਤੀਆਂ ਨਾਲ ਪ੍ਰਮਾਣਿਕਤਾ ਡੇਟਾ ਨੱਥੀ ਕਰੋ;
• ਨੋਡ ਜੇਐਸ ਲੇਅਰਾਂ ਨੂੰ ਦੋ ਵੱਖਰੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਵੰਡੋ।

ਪਹਿਲੇ ਹੱਲ ਲਈ ਸਰਵਰ 'ਤੇ ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਦੀ ਵਰਤੋਂ ਦੀ ਲੋੜ ਸੀ, ਅਤੇ ਦੂਜੇ ਨੇ ਕੰਮ ਨੂੰ ਪੂਰਾ ਕਰਨ ਦੀ ਸਮਾਂ ਸੀਮਾ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਮਹੀਨੇ ਤੱਕ ਵਧਾ ਦਿੱਤੀ।

ਇੱਕ ਚੋਣ ਕਿਵੇਂ ਕਰੀਏ? ਹੈਬਰ ਅਕਸਰ ਘੱਟ ਤੋਂ ਘੱਟ ਵਿਰੋਧ ਦੇ ਮਾਰਗ ਦੇ ਨਾਲ ਅੱਗੇ ਵਧਦਾ ਹੈ। ਗੈਰ-ਰਸਮੀ ਤੌਰ 'ਤੇ, ਵਿਚਾਰ ਤੋਂ ਪ੍ਰੋਟੋਟਾਈਪ ਤੱਕ ਚੱਕਰ ਨੂੰ ਘੱਟੋ-ਘੱਟ ਕਰਨ ਦੀ ਇੱਕ ਆਮ ਇੱਛਾ ਹੈ. ਉਤਪਾਦ ਪ੍ਰਤੀ ਰਵੱਈਏ ਦਾ ਮਾਡਲ ਕੁਝ ਹੱਦ ਤੱਕ booking.com ਦੇ ਅਸੂਲਾਂ ਦੀ ਯਾਦ ਦਿਵਾਉਂਦਾ ਹੈ, ਸਿਰਫ ਫਰਕ ਇਹ ਹੈ ਕਿ ਹੈਬਰ ਉਪਭੋਗਤਾ ਦੇ ਫੀਡਬੈਕ ਨੂੰ ਵਧੇਰੇ ਗੰਭੀਰਤਾ ਨਾਲ ਲੈਂਦਾ ਹੈ ਅਤੇ ਅਜਿਹੇ ਫੈਸਲੇ ਲੈਣ ਲਈ, ਇੱਕ ਡਿਵੈਲਪਰ ਵਜੋਂ, ਤੁਹਾਡੇ 'ਤੇ ਭਰੋਸਾ ਕਰਦਾ ਹੈ।

ਇਸ ਤਰਕ ਅਤੇ ਸਮੱਸਿਆ ਨੂੰ ਜਲਦੀ ਹੱਲ ਕਰਨ ਦੀ ਮੇਰੀ ਆਪਣੀ ਇੱਛਾ ਦੇ ਬਾਅਦ, ਮੈਂ ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਚੁਣਿਆ. ਅਤੇ, ਜਿਵੇਂ ਕਿ ਅਕਸਰ ਹੁੰਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਜਲਦੀ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਉਹਨਾਂ ਲਈ ਭੁਗਤਾਨ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਅਸੀਂ ਲਗਭਗ ਤੁਰੰਤ ਭੁਗਤਾਨ ਕੀਤਾ: ਅਸੀਂ ਸ਼ਨੀਵਾਰ ਤੇ ਕੰਮ ਕੀਤਾ, ਨਤੀਜਿਆਂ ਨੂੰ ਸਾਫ਼ ਕੀਤਾ, ਲਿਖਿਆ ਪੋਸਟ ਮਾਰਟਮ ਅਤੇ ਸਰਵਰ ਨੂੰ ਦੋ ਹਿੱਸਿਆਂ ਵਿੱਚ ਵੰਡਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ। ਗਲਤੀ ਬਹੁਤ ਮੂਰਖ ਸੀ, ਅਤੇ ਇਸ ਵਿੱਚ ਸ਼ਾਮਲ ਬੱਗ ਨੂੰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰਨਾ ਆਸਾਨ ਨਹੀਂ ਸੀ। ਅਤੇ ਹਾਂ, ਇਹ ਇਸ ਲਈ ਸ਼ਰਮ ਦੀ ਗੱਲ ਹੈ, ਪਰ ਇੱਕ ਜਾਂ ਦੂਜੇ ਤਰੀਕੇ ਨਾਲ, ਠੋਕਰ ਅਤੇ ਹਾਹਾਕਾਰ, ਗਲੋਬਲ ਵੇਰੀਏਬਲਾਂ ਵਾਲਾ ਮੇਰਾ ਪੀਓਸੀ ਫਿਰ ਵੀ ਉਤਪਾਦਨ ਵਿੱਚ ਚਲਾ ਗਿਆ ਅਤੇ ਇੱਕ ਨਵੇਂ "ਦੋ-ਨੋਡ" ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਜਾਣ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹੋਏ ਕਾਫ਼ੀ ਸਫਲਤਾਪੂਰਵਕ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ। ਇਹ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਕਦਮ ਸੀ, ਕਿਉਂਕਿ ਰਸਮੀ ਤੌਰ 'ਤੇ ਟੀਚਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਸੀ - SSR ਨੇ ਵਰਤੋਂ ਲਈ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਪੰਨੇ ਨੂੰ ਡਿਲੀਵਰ ਕਰਨਾ ਸਿੱਖਿਆ, ਅਤੇ UI ਬਹੁਤ ਸ਼ਾਂਤ ਹੋ ਗਿਆ।

ਰਿਫੈਕਟਰਿੰਗ ਦੇ ਪਹਿਲੇ ਪੜਾਅ ਤੋਂ ਬਾਅਦ ਮੋਬਾਈਲ ਹੈਬਰ ਇੰਟਰਫੇਸ

ਆਖਰਕਾਰ, ਮੋਬਾਈਲ ਸੰਸਕਰਣ ਦਾ SSR-CSR ਆਰਕੀਟੈਕਚਰ ਇਸ ਤਸਵੀਰ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ:

"ਦੋ-ਨੋਡ" SSR-CSR ਸਰਕਟ. ਨੋਡ JS API ਹਮੇਸ਼ਾ ਅਸਿੰਕ੍ਰੋਨਸ I/O ਲਈ ਤਿਆਰ ਹੁੰਦਾ ਹੈ ਅਤੇ SSR ਫੰਕਸ਼ਨ ਦੁਆਰਾ ਬਲੌਕ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਬਾਅਦ ਵਾਲਾ ਇੱਕ ਵੱਖਰੀ ਸਥਿਤੀ ਵਿੱਚ ਸਥਿਤ ਹੈ। ਪੁੱਛਗਿੱਛ ਲੜੀ #3 ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

ਡੁਪਲੀਕੇਟ ਬੇਨਤੀਆਂ ਨੂੰ ਖਤਮ ਕਰਨਾ

ਹੇਰਾਫੇਰੀ ਕੀਤੇ ਜਾਣ ਤੋਂ ਬਾਅਦ, ਪੰਨੇ ਦੀ ਸ਼ੁਰੂਆਤੀ ਰੈਂਡਰਿੰਗ ਨੇ ਹੁਣ ਮਿਰਗੀ ਨੂੰ ਭੜਕਾਇਆ ਨਹੀਂ। ਪਰ SPA ਮੋਡ ਵਿੱਚ ਹੈਬਰ ਦੀ ਹੋਰ ਵਰਤੋਂ ਨੇ ਅਜੇ ਵੀ ਉਲਝਣ ਪੈਦਾ ਕੀਤੀ.

ਕਿਉਂਕਿ ਉਪਭੋਗਤਾ ਵਹਾਅ ਦਾ ਅਧਾਰ ਫਾਰਮ ਦਾ ਪਰਿਵਰਤਨ ਹੁੰਦਾ ਹੈ ਲੇਖਾਂ ਦੀ ਸੂਚੀ → ਲੇਖ → ਟਿੱਪਣੀਆਂ ਅਤੇ ਇਸਦੇ ਉਲਟ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਇਸ ਲੜੀ ਦੇ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਉਣਾ ਮਹੱਤਵਪੂਰਨ ਸੀ।

ਪੋਸਟ ਫੀਡ 'ਤੇ ਵਾਪਸ ਜਾਣਾ ਇੱਕ ਨਵੀਂ ਡੇਟਾ ਬੇਨਤੀ ਨੂੰ ਭੜਕਾਉਂਦਾ ਹੈ

ਡੂੰਘੀ ਖੁਦਾਈ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਸੀ। ਉੱਪਰ ਦਿੱਤੇ ਸਕਰੀਨਕਾਸਟ ਵਿੱਚ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਵਾਪਸ ਸਵਾਈਪ ਕਰਨ 'ਤੇ ਲੇਖਾਂ ਦੀ ਸੂਚੀ ਦੀ ਦੁਬਾਰਾ ਬੇਨਤੀ ਕਰਦੀ ਹੈ, ਅਤੇ ਬੇਨਤੀ ਦੇ ਦੌਰਾਨ ਅਸੀਂ ਲੇਖ ਨਹੀਂ ਵੇਖਦੇ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪਿਛਲਾ ਡੇਟਾ ਕਿਤੇ ਗਾਇਬ ਹੋ ਜਾਂਦਾ ਹੈ। ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਲੇਖ ਸੂਚੀ ਭਾਗ ਇੱਕ ਸਥਾਨਕ ਸਥਿਤੀ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਤਬਾਹ ਕਰਨ 'ਤੇ ਗੁਆ ਦਿੰਦਾ ਹੈ। ਵਾਸਤਵ ਵਿੱਚ, ਐਪਲੀਕੇਸ਼ਨ ਨੇ ਇੱਕ ਗਲੋਬਲ ਸਟੇਟ ਦੀ ਵਰਤੋਂ ਕੀਤੀ, ਪਰ 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 },
  ...
}

ਲੇਖਾਂ ਦੀ ਸੂਚੀ ਇੱਥੇ ਇਹ ਲੇਖਾਂ ਦੀ ਇੱਕ ਕਿਸਮ ਦਾ ਭੰਡਾਰ ਹੈ। ਉਹ ਸਾਰੇ ਲੇਖ ਜੋ ਉਪਭੋਗਤਾ ਸੈਸ਼ਨ ਦੌਰਾਨ ਡਾਊਨਲੋਡ ਕੀਤੇ ਗਏ ਸਨ। ਅਸੀਂ ਉਹਨਾਂ ਨੂੰ ਪੂਰੀ ਸਾਵਧਾਨੀ ਨਾਲ ਵਰਤਦੇ ਹਾਂ, ਕਿਉਂਕਿ ਇਹ ਉਹ ਟ੍ਰੈਫਿਕ ਹੈ ਜੋ ਸ਼ਾਇਦ ਸਟੇਸ਼ਨਾਂ ਦੇ ਵਿਚਕਾਰ ਮੈਟਰੋ ਵਿੱਚ ਦਰਦ ਦੁਆਰਾ ਡਾਊਨਲੋਡ ਕੀਤਾ ਗਿਆ ਹੋਵੇ, ਅਤੇ ਅਸੀਂ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਉਸ ਡੇਟਾ ਨੂੰ ਲੋਡ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਕੇ ਦੁਬਾਰਾ ਇਸ ਦਰਦ ਦਾ ਕਾਰਨ ਨਹੀਂ ਬਣਨਾ ਚਾਹੁੰਦੇ ਜੋ ਉਸ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਹੈ। ਡਾਊਨਲੋਡ ਕੀਤਾ। ਇੱਕ ਵਸਤੂ ਲੇਖ ਆਈਡੀਆਂ ਵਸਤੂਆਂ ਲਈ ਸਿਰਫ਼ ਆਈਡੀ ਦੀ ਇੱਕ ਲੜੀ ਹੈ (ਜਿਵੇਂ "ਲਿੰਕ") ਲੇਖ. ਇਹ ਢਾਂਚਾ ਤੁਹਾਨੂੰ ਰੂਟਾਂ ਲਈ ਆਮ ਡਾਟਾ ਡੁਪਲੀਕੇਟ ਕਰਨ ਅਤੇ ਵਸਤੂ ਦੀ ਮੁੜ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਬਚਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਲੇਖ ਜਦੋਂ ਇਸ ਵਿੱਚ ਵਿਸਤ੍ਰਿਤ ਡੇਟਾ ਨੂੰ ਮਿਲਾ ਕੇ ਇੱਕ ਪੋਸਟ ਪੇਜ ਰੈਂਡਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਲੇਖਾਂ ਦੀ ਸੂਚੀ ਦਾ ਆਉਟਪੁੱਟ ਵੀ ਵਧੇਰੇ ਪਾਰਦਰਸ਼ੀ ਹੋ ਗਿਆ ਹੈ: ਇਟਰੇਟਰ ਕੰਪੋਨੈਂਟ ਆਰਟੀਕਲ ਆਈਡੀ ਦੇ ਨਾਲ ਐਰੇ ਰਾਹੀਂ ਦੁਹਰਾਉਂਦਾ ਹੈ ਅਤੇ ਲੇਖ ਟੀਜ਼ਰ ਕੰਪੋਨੈਂਟ ਨੂੰ ਖਿੱਚਦਾ ਹੈ, ਆਈਡੀ ਨੂੰ ਪ੍ਰੋਪ ਵਜੋਂ ਪਾਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਚਾਈਲਡ ਕੰਪੋਨੈਂਟ, ਬਦਲੇ ਵਿੱਚ, ਲੋੜੀਂਦੇ ਡੇਟਾ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਲੇਖਾਂ ਦੀ ਸੂਚੀ. ਜਦੋਂ ਤੁਸੀਂ ਪ੍ਰਕਾਸ਼ਨ ਪੰਨੇ 'ਤੇ ਜਾਂਦੇ ਹੋ, ਤਾਂ ਸਾਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਤਾਰੀਖ ਮਿਲਦੀ ਹੈ ਲੇਖਾਂ ਦੀ ਸੂਚੀ, ਅਸੀਂ ਗੁੰਮ ਹੋਏ ਡੇਟਾ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਬੇਨਤੀ ਕਰਦੇ ਹਾਂ ਅਤੇ ਇਸਨੂੰ ਮੌਜੂਦਾ ਵਸਤੂ ਵਿੱਚ ਜੋੜਦੇ ਹਾਂ।

ਇਹ ਪਹੁੰਚ ਬਿਹਤਰ ਕਿਉਂ ਹੈ? ਜਿਵੇਂ ਕਿ ਮੈਂ ਉੱਪਰ ਲਿਖਿਆ ਹੈ, ਇਹ ਪਹੁੰਚ ਡਾਉਨਲੋਡ ਕੀਤੇ ਡੇਟਾ ਦੇ ਸਬੰਧ ਵਿੱਚ ਵਧੇਰੇ ਕੋਮਲ ਹੈ ਅਤੇ ਤੁਹਾਨੂੰ ਇਸਨੂੰ ਦੁਬਾਰਾ ਵਰਤਣ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਪਰ ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਕੁਝ ਨਵੀਆਂ ਸੰਭਾਵਨਾਵਾਂ ਦਾ ਰਾਹ ਖੋਲ੍ਹਦਾ ਹੈ ਜੋ ਅਜਿਹੀ ਆਰਕੀਟੈਕਚਰ ਵਿੱਚ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫਿੱਟ ਹੁੰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਪੋਲਿੰਗ ਅਤੇ ਲੇਖਾਂ ਨੂੰ ਫੀਡ ਵਿੱਚ ਲੋਡ ਕਰਨਾ ਜਿਵੇਂ ਉਹ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ। ਅਸੀਂ ਬਸ ਇੱਕ "ਸਟੋਰੇਜ" ਵਿੱਚ ਨਵੀਨਤਮ ਪੋਸਟਾਂ ਪਾ ਸਕਦੇ ਹਾਂ ਲੇਖਾਂ ਦੀ ਸੂਚੀਵਿੱਚ ਨਵੀਂ ਆਈਡੀ ਦੀ ਇੱਕ ਵੱਖਰੀ ਸੂਚੀ ਸੁਰੱਖਿਅਤ ਕਰੋ ਲੇਖ ਆਈਡੀਆਂ ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਇਸ ਬਾਰੇ ਸੂਚਿਤ ਕਰੋ। ਜਦੋਂ ਅਸੀਂ "ਨਵੇਂ ਪ੍ਰਕਾਸ਼ਨ ਦਿਖਾਓ" ਬਟਨ 'ਤੇ ਕਲਿੱਕ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਲੇਖਾਂ ਦੀ ਮੌਜੂਦਾ ਸੂਚੀ ਦੀ ਲੜੀ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਨਵੇਂ ਆਈਡੀ ਸ਼ਾਮਲ ਕਰਾਂਗੇ ਅਤੇ ਹਰ ਚੀਜ਼ ਲਗਭਗ ਜਾਦੂਈ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰੇਗੀ।

ਡਾਊਨਲੋਡਿੰਗ ਨੂੰ ਹੋਰ ਮਜ਼ੇਦਾਰ ਬਣਾਉਣਾ

ਰੀਫੈਕਟਰਿੰਗ ਕੇਕ 'ਤੇ ਆਈਸਿੰਗ ਪਿੰਜਰ ਦੀ ਧਾਰਨਾ ਹੈ, ਜੋ ਹੌਲੀ ਇੰਟਰਨੈਟ 'ਤੇ ਸਮੱਗਰੀ ਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਥੋੜਾ ਘੱਟ ਘਿਣਾਉਣੀ ਬਣਾਉਂਦਾ ਹੈ। ਇਸ ਮਾਮਲੇ 'ਤੇ ਕੋਈ ਵਿਚਾਰ-ਵਟਾਂਦਰਾ ਨਹੀਂ ਹੋਇਆ; ਵਿਚਾਰ ਤੋਂ ਪ੍ਰੋਟੋਟਾਈਪ ਤੱਕ ਦਾ ਰਸਤਾ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਦੋ ਘੰਟੇ ਲੱਗ ਗਿਆ। ਡਿਜ਼ਾਈਨ ਨੇ ਵਿਵਹਾਰਕ ਤੌਰ 'ਤੇ ਆਪਣੇ ਆਪ ਨੂੰ ਖਿੱਚਿਆ, ਅਤੇ ਅਸੀਂ ਡੇਟਾ ਦੀ ਉਡੀਕ ਕਰਦੇ ਹੋਏ ਆਪਣੇ ਭਾਗਾਂ ਨੂੰ ਸਧਾਰਨ, ਮੁਸ਼ਕਿਲ ਨਾਲ ਫਲਿੱਕਰਿੰਗ ਡਿਵ ਬਲਾਕਾਂ ਨੂੰ ਰੈਂਡਰ ਕਰਨਾ ਸਿਖਾਇਆ। ਵਿਅਕਤੀਗਤ ਤੌਰ 'ਤੇ, ਲੋਡਿੰਗ ਲਈ ਇਹ ਪਹੁੰਚ ਅਸਲ ਵਿੱਚ ਉਪਭੋਗਤਾ ਦੇ ਸਰੀਰ ਵਿੱਚ ਤਣਾਅ ਦੇ ਹਾਰਮੋਨਾਂ ਦੀ ਮਾਤਰਾ ਨੂੰ ਘਟਾਉਂਦੀ ਹੈ। ਪਿੰਜਰ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

ਹੈਬਰਾਲੋਡਿੰਗ

ਪ੍ਰਤੀਬਿੰਬਤ

ਮੈਂ ਛੇ ਮਹੀਨਿਆਂ ਤੋਂ ਹੈਬਰੇ ਵਿੱਚ ਕੰਮ ਕਰ ਰਿਹਾ ਹਾਂ ਅਤੇ ਮੇਰੇ ਦੋਸਤ ਅਜੇ ਵੀ ਪੁੱਛਦੇ ਹਨ: ਠੀਕ ਹੈ, ਤੁਹਾਨੂੰ ਉੱਥੇ ਇਹ ਕਿਵੇਂ ਪਸੰਦ ਹੈ? ਠੀਕ ਹੈ, ਆਰਾਮਦਾਇਕ - ਹਾਂ। ਪਰ ਕੁਝ ਅਜਿਹਾ ਹੈ ਜੋ ਇਸ ਕੰਮ ਨੂੰ ਦੂਜਿਆਂ ਨਾਲੋਂ ਵੱਖਰਾ ਬਣਾਉਂਦਾ ਹੈ। ਮੈਂ ਉਹਨਾਂ ਟੀਮਾਂ ਵਿੱਚ ਕੰਮ ਕੀਤਾ ਜੋ ਉਹਨਾਂ ਦੇ ਉਤਪਾਦ ਪ੍ਰਤੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਉਦਾਸੀਨ ਸਨ, ਉਹਨਾਂ ਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਸੀ ਕਿ ਉਹਨਾਂ ਦੇ ਉਪਭੋਗਤਾ ਕੌਣ ਸਨ. ਪਰ ਇੱਥੇ ਸਭ ਕੁਝ ਵੱਖਰਾ ਹੈ. ਇੱਥੇ ਤੁਸੀਂ ਆਪਣੇ ਕੰਮ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ। ਕਿਸੇ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ, ਤੁਸੀਂ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ ਇਸਦੇ ਮਾਲਕ ਬਣ ਜਾਂਦੇ ਹੋ, ਤੁਹਾਡੀ ਕਾਰਜਸ਼ੀਲਤਾ ਨਾਲ ਸਬੰਧਤ ਸਾਰੀਆਂ ਉਤਪਾਦ ਮੀਟਿੰਗਾਂ ਵਿੱਚ ਹਿੱਸਾ ਲੈਂਦੇ ਹੋ, ਸੁਝਾਅ ਦਿੰਦੇ ਹੋ ਅਤੇ ਆਪਣੇ ਆਪ ਫੈਸਲੇ ਲੈਂਦੇ ਹੋ। ਇੱਕ ਉਤਪਾਦ ਬਣਾਉਣਾ ਜਿਸਨੂੰ ਤੁਸੀਂ ਹਰ ਰੋਜ਼ ਵਰਤਦੇ ਹੋ, ਬਹੁਤ ਵਧੀਆ ਹੈ, ਪਰ ਉਹਨਾਂ ਲੋਕਾਂ ਲਈ ਕੋਡ ਲਿਖਣਾ ਜੋ ਸ਼ਾਇਦ ਤੁਹਾਡੇ ਨਾਲੋਂ ਇਸ ਵਿੱਚ ਬਿਹਤਰ ਹਨ ਸਿਰਫ਼ ਇੱਕ ਸ਼ਾਨਦਾਰ ਭਾਵਨਾ ਹੈ (ਕੋਈ ਵਿਅੰਗ ਨਹੀਂ)।

ਇਹਨਾਂ ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਦੇ ਜਾਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਸਾਨੂੰ ਸਕਾਰਾਤਮਕ ਫੀਡਬੈਕ ਪ੍ਰਾਪਤ ਹੋਇਆ, ਅਤੇ ਇਹ ਬਹੁਤ, ਬਹੁਤ ਵਧੀਆ ਸੀ। ਇਹ ਪ੍ਰੇਰਨਾਦਾਇਕ ਹੈ। ਤੁਹਾਡਾ ਧੰਨਵਾਦ! ਹੋਰ ਲਿਖੋ।

ਮੈਨੂੰ ਤੁਹਾਨੂੰ ਯਾਦ ਦਿਵਾਉਣ ਦਿਓ ਕਿ ਗਲੋਬਲ ਵੇਰੀਏਬਲ ਤੋਂ ਬਾਅਦ ਅਸੀਂ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਬਦਲਣ ਅਤੇ ਪ੍ਰੌਕਸੀ ਲੇਅਰ ਨੂੰ ਇੱਕ ਵੱਖਰੀ ਉਦਾਹਰਣ ਵਿੱਚ ਨਿਰਧਾਰਤ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ। "ਦੋ-ਨੋਡ" ਆਰਕੀਟੈਕਚਰ ਪਹਿਲਾਂ ਹੀ ਜਨਤਕ ਬੀਟਾ ਟੈਸਟਿੰਗ ਦੇ ਰੂਪ ਵਿੱਚ ਰਿਲੀਜ਼ ਤੱਕ ਪਹੁੰਚ ਗਿਆ ਹੈ. ਹੁਣ ਕੋਈ ਵੀ ਇਸ 'ਤੇ ਸਵਿਚ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਮੋਬਾਈਲ ਹੈਬਰ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਅੱਜ ਲਈ ਇਹ ਸਭ ਕੁਝ ਹੈ। ਮੈਨੂੰ ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਤੁਹਾਡੇ ਸਾਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦੇਣ ਵਿੱਚ ਖੁਸ਼ੀ ਹੋਵੇਗੀ.

ਸਰੋਤ: www.habr.com