27 ਨਵੰ 2025·8 ਮਿੰਟ
ਜੋਰਡਨ ਵਾਕ ਅਤੇ React: ਕਿਵੇਂ ਕੰਪੋਨੈਂਟਾਂ ਨੇ UI ਆਰਕੀਟੈਕਚਰ ਬਦਲ ਦਿੱਤਾ
ਜਾਣੋ ਕਿ ਕਿਵੇਂ Jordan Walke ਦੀ React ਨੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਕੰਪੋਨੈਂਟ, ਡਿਕਲੇਰਟਿਵ ਵਿਊ ਅਤੇ ਸਟੇਟ-ਡ੍ਰਿਵਨ ਰੈਂਡਰਿੰਗ ਰਾਹੀਂ ਆਧੁਨਿਕ ਫਰੰਟਐਂਡ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਬਦਲ ਦਿੱਤਾ।
ਜਾਣੋ ਕਿ ਕਿਵੇਂ Jordan Walke ਦੀ React ਨੇ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਕੰਪੋਨੈਂਟ, ਡਿਕਲੇਰਟਿਵ ਵਿਊ ਅਤੇ ਸਟੇਟ-ਡ੍ਰਿਵਨ ਰੈਂਡਰਿੰਗ ਰਾਹੀਂ ਆਧੁਨਿਕ ਫਰੰਟਐਂਡ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਬਦਲ ਦਿੱਤਾ।
Jordan Walke ਇੱਕ ਸਾਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰ ਹਨ ਜੋ Facebook ਵਿਚ ਕੰਮ ਕਰਦੇ ਸਮੇਂ React ਬਣਾਉਣ ਲਈ ਮਸ਼ਹੂਰ ਹੋਏ। React ਤੋਂ ਪਹਿਲਾਂ, ਫਰੰਟਐਂਡ ਅਕਸਰ ਪੇਜ਼ਾਂ, ਟੈਂਪਲੇਟਾਂ ਅਤੇ ਇੱਕ ਵੱਧਦੀ "ਗਲੂ ਕੋਡ" ਦੀ ਢੇਰ 'ਤੇ ਬਣੇ ਹੁੰਦੇ ਸਨ ਜੋ HTML, CSS ਅਤੇ JavaScript ਨੂੰ ਮਿਲਾਵਟ ਵਿੱਚ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਸੀ। Walke ਦਾ ਮੁੱਖ ਵਿਚਾਰ ਇਹ ਸੀ ਕਿ ਮਾਡਲ ਨੂੰ ਉਲਟ ਦਿੱਤਾ ਜਾਵੇ: UI ਨੂੰ ਉਹਨਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਵਾਂਗ ਨਾ ਦੇਖੋ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਪੈਚ ਕਰਦੇ ਹੋ, ਬਲਕਿ ਇਸਨੂੰ ਛੋਟੇ, ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਕੰਪੋਨੈਂਟਾਂ ਦੇ ਰੁੱਖ ਵਜੋਂ ਸੋਚੋ ਜੋ ਤੁਸੀਂ ਵੱਡੀਆਂ ਫੀਚਰਾਂ ਲਈ ਜੋੜਦੇ ਹੋ।
ਇਹ ਸਿਰਫ਼ ਇੱਕ ਨਵਾਂ ਲਾਇਬ੍ਰੇਰੀ ਨਹੀਂ ਸੀ—ਇਹ UI ਕੰਮ ਬਾਰੇ ਸੋਚਣ ਦਾ ਇੱਕ ਨਵਾਂ ਤਰੀਕਾ ਸੀ। ਇੱਕ ਕੰਪੋਨੈਂਟ ਇੱਕ ਹਿੱਸਾ-ਇੰਟਰਫੇਸ ਨਾਲ ਉਸ ਦੀ ਲੌਜਿਕ ਅਤੇ ਸਟੇਟ ਬੰਨ੍ਹਦਾ ਹੈ, ਫਿਰ ਬਾਕੀ ਐਪ ਨੂੰ ਇੱਕ ਸਾਫ਼ ਇੰਟਰਫੇਸ (props) ਦਿੰਦਾ ਹੈ। ਇਸ ਨਾਲ UI ਲੈਗੋ ਇੱਟਾਂ ਨਾਲ ਬਣਾਉਣ ਵਰਗਾ ਮਹਿਸੂਸ ਹੋਦਾ ਹੈ ਨਾ ਕਿ ਇੱਕ ਨਜ਼ੁਕ ਸਿੰਗਲ ਪੇਜ਼ ਵਿੱਚ ਸੋਧ ਕਰਨ ਵਰਗਾ।
React ਇਸ ਲਈ ਮੁੱਖ ਸੀ ਕਿਉਂਕਿ ਇਸ ਨੇ ਟੀਮਾਂ ਨੂੰ ਮਦਦ ਕੀਤੀ:
ਅਸੀਂ ਉਨ੍ਹਾਂ ਅਮਲੀ ਵਿਚਾਰਾਂ ਨੂੰ ਵੇਖਾਂਗੇ ਜਿਨ੍ਹਾਂ ਨੇ React ਨੂੰ ਪ੍ਰਭਾਵਸ਼ালী ਬਣਾਇਆ:
ਤੁਹਾਨੂੰ ਫਰੇਮਵਰਕ-ਮਾਹਿਰ ਹੋਣ ਦੀ ਲੋੜ ਨਹੀਂ—ਮਕਸਦ ਮੈਨਟਲ ਮਾਡਲ ਸਪਸ਼ਟ ਕਰਨਾ ਹੈ ਤਾਂ ਕਿ ਤੁਸੀਂ ਚੰਗੇ React ਪੈਟਰਨਾਂ ਨੂੰ ਪਛਾਣ ਸਕੋ, ਆਮ ਗਲਤфਹਿਮੀਆਂ ਤੋਂ ਬਚ ਸਕੋ, ਅਤੇ ਇਹzelfde ਸਿਧਾਂਤ React ਤੋਂ ਬਾਹਰ ਵੀ ਲਾਗੂ ਕਰ ਸਕੋ।
React ਤੋਂ ਪਹਿਲਾਂ, ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਨੇ ਰਿਚ ਇੰਟਰਫੇਸ ਟੈਂਪਲੇਟਾਂ, jQuery-ਸਟਾਈਲ DOM ਸੋਧਾਂ, ਅਤੇ "ਜਦੋਂ X ਹੋਵੇ ਤਾਂ Y ਅਪਡੇਟ ਕਰੋ" ਨਿਯਮਾਂ ਦੀ ਚੇਨ ਬਣਾਕੇ ਤਿਆਰ ਕੀਤੇ। ਇਹ ਕੰਮ ਕਰਦਾ ਸੀ—ਜਦ ਤੱਕ UI ਵਿਅਸਤ ਨਾ ਹੋ ਜਾਵੇ।
ਸਧਾਰਨ ਨਮੂਨਾ ਇਹ ਸੀ: ਡੇਟਾ ਲਾਓ, HTML ਰੈਂਡਰ ਕਰੋ, ਫਿਰ ਇਵੈਂਟ ਹੈਂਡਲਰ ਜੁੜਾਓ ਜੋ DOM ਨੂੰ ਸਿੱਧਾ ਬਦਲ ਦੇਂਦੇ। ਜਦੋਂ ਸਟੇਟ ਬਦਲ ਜਾਂਦੀ (ਨਵੀਂ ਆਈਟਮ, ਵੈਰੀਫਿਕੇਸ਼ਨ ਐਰਰ, ਟੌਗਲ), ਤਦ ਕਿਸੇ ਨੇ ਉਹ ਹਰ ਥਾਂ ਯਾਦ ਰੱਖਣੀ ਪੈਂਦੀ ਜਿਸ ਤੇ ਇਸ ਦਾ ਨਿਰਭਰਤਾ ਸੀ।
ਇਸ ਨਾਲ ਬਗ ਆਉਂਦੇ ਜਿਵੇਂ:
ਜਿਵੇਂ ਸਕ੍ਰੀਨਾਂ ਵਿਕਸਿਤ ਹੋਈਆਂ, ਉਹੇ ਹੀ ਬਿਜ਼ਨਸ ਨਿਯਮ ਕਈ ਹੈਂਡਲਰਾਂ ਵਿੱਚ ਨਕਲ ਹੋ ਗਏ: “ਫੀਲਡ ਖਾਲੀ ਹੋਵੇ ਤਾਂ ਬਟਨ ਅਯੋਗ ਕਰੋ”, “ਅਪਠਿਤ ਆਈਟਮ ਹਾਈਲਾਈਟ ਕਰੋ”, “ਕੋਈ ਨਤੀਜੇ ਨਹੀਂ ਤਾਂ empty state ਦਿਖਾਓ।” ਜਦੋਂ ਲੋੜ ਬਦਲੀ, ਤੁਹਾਨੂੰ ਹਰ ਨਕਲ ਨੂੰ ਅਲੱਗ ਫਾਇਲਾਂ ਵਿੱਚ ਖੋਜ ਕੇ ਅਪਡੇਟ ਕਰਨਾ ਪੈਂਦਾ।
ਡੇਟਾ ਨੂੰ ਕੁਝ ਸਪਸ਼ਟ ਸਾਂਚਿਆਂ ਨਾਲ ਮਾਡਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਪੋਸਟਾਂ ਦੀ ਲਿਸਟ, ਯੂਜ਼ਰ ਬਜੈਕਟ, ਫਿਲਟਰ। ਪਰ UI ਮਿਲਾਵਟਾਂ ਲਿਆਉਂਦਾ ਹੈ: ਲੋਡ ਹੋ ਰਿਹਾ ਹੈ ਬਨਾਮ ਲੋਡ ਹੋਇਆ, ਐਰਰ ਬਨਾਮ ਸੱਫਲਤਾ, ਪੜ੍ਹਿਆ ਬਨਾਮ ਅਪੜ੍ਹਿਆ, ਸੰਪਾਦਨ ਬਨਾਮ ਵੇਖਣ—ਅਕਸਰ ਸਭ ਇਕੱਠੇ।
ਇੱਕ ਨਿਊਜ਼ ਫੀਡ ਦੀ ਕਲਪਨਾ ਕਰੋ:
"UI ਸਟੇਟ ਦਾ ਫੰਕਸ਼ਨ" ਵਰਗਾ ਸਪਸ਼ਟ ਨਿਯਮ ਨਾ ਹੋਵੇ ਤਾਂ ਤੁਹਾਨੂੰ ਬਹੁਤ ਸਾਰੀਆਂ DOM ਸੋਧਾਂ ਨੂੰ ਕੋਆਰਡੀਨੇਟ ਕਰਨਾ ਪੈਦਾ ਜੋ ਟਕਰਾਉ ਸਕਦੀਆਂ ਹਨ। React ਦਾ ਲਕਸ਼ ਹੈ ਕਿ ਅਪਡੇਟ ਭਰੋਸੇਯੋਗ ਹੋਣ: ਡੇਟਾ/ਸਟੇਟ ਬਦਲੋ, ਅਤੇ UI ਹਮੇਸ਼ਾਂ ਉਸਨੂੰ ਮਿਲਾਉਂਦਾ ਹੈ।
ਇੱਕ ਕੰਪੋਨੈਂਟ UI ਦਾ ਛੋਟਾ ਹਿੱਸਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਨਾਮ ਦੇ ਸਕਦੇ ਹੋ, ਦੁਹਰਾਅ ਸਕਦੇ ਹੋ, ਅਤੇ ਅਲੱਗ ਤੌਰ 'ਤੇ ਸੋਚ ਸਕਦੇ ਹੋ। ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ: ਇੱਕ ਕੰਪੋਨੈਂਟ ਸਰਗਰਮੀ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਉਨ੍ਹਾਂ ਇਨਪੁਟਸ ਲਈ UI ਕਿਵੇਂ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ ਵਾਪਸ ਕਰਦਾ ਹੈ।
ਇਹ "ਇਨਪੁਟ → ਆਊਟਪੁੱਟ" ਫਰੇਮਿੰਗ ਕੰਪੋਨੈਂਟ ਮਾਡਲ ਦੀ ਰੂਹ ਹੈ। ਸਕਰੀਨ ਨੂੰ ਇੱਕ ਵੱਡੇ ਟੈਂਪਲੇਟ ਵਜੋਂ ਦੇਖਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਇਸਨੂੰ ਲਕੜੀ ਦੇ ਟੁਕੜਿਆਂ ਵਾਂਗ ਵੰਡਦੇ ਹੋ—ਬਟਨ, ਕਾਰਡ, ਮੇਨੂ, ਫਾਰਮ ਅਤੇ ਪੂਰੇ ਸੈਕਸ਼ਨ—ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਜੋੜਦੇ ਹੋ।
React ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ਇਨਪੁਟ props ਹਨ। Props ਉਹ ਮੁੱਲ ਹਨ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਕੰਪੋਨੈਂਟ ਨੂੰ ਦਿੰਦੇ ਹੋ ਤਾਂ ਜੋ ਉਹ ਆਪਣੇ ਲਈ ਕੰਫਿਗਰ ਹੋਵੇ: ਟੈਕਸਟ, ਨੰਬਰ, ਫਲੈਗ, ਇਵੈਂਟ ਹੈਂਡਲਰ, ਜਾਂ ਹੋਰ UI।
ਆਊਟਪੁੱਟ ਉਹ UI ਹੈ ਜੋ ਕੰਪੋਨੈਂਟ ਰੈਂਡਰ ਕਰਦਾ ਹੈ। ਜੇ props ਬਦਲਦੇ ਹਨ, ਕੰਪੋਨੈਂਟ ਵੱਖਰਾ ਆਊਟਪੁੱਟ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ—ਤੁਹਾਡੇ DOM ਨੂੰ ਮੈਨੁਅਲ ਤੌਰ 'ਤੇ ਖੋਜਣ ਦੀ ਲੋੜ ਨਹੀਂ।
ਉਦਾਹਰਣ ਲਈ, ਇੱਕ Button ਕੰਪੋਨੈਂਟ label, disabled, ਅਤੇ onClick ਵਰਗੇ props ਲੈ ਸਕਦਾ ਹੈ। UserCard name, avatarUrl, ਅਤੇ status ਲੈ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਕੰਪੋਨੈਂਟ ਦੀ ਇੰਟਰਫੇਸ (ਇਸਦੇ props) ਨੂੰ ਐਸਾ ਹੀ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਜਿਵੇਂ ਤੁਸੀਂ ਇੱਕ ਪ੍ਰੋਡਕਟ ਸਪੈੱਕ ਪੜ੍ਹਦੇ ਹੋ: "ਇਸ UI ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਰੈਂਡਰ ਕਰਨ ਲਈ ਇਸਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ?"
UI ਨੂੰ ਕੰਪੋਨੈਂਟਾਂ ਵਿੱਚ ਤੋੜਨ ਦੇ ਫਾਇਦੇ ਜਲਦੀ ਮਿਲਦੇ ਹਨ:
Modal, Input, ਜਾਂ Dropdown ਕਈ ਪੇਜਾਂ 'ਤੇ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ।ਇਹ ਕਾਪੀ ਅਤੇ ਮਾਰਕਅੱਪ ਪ੍ਰਤੀਰੂਪ ਕਰਨ ਤੋਂ ਬਹੁਤ ਵੱਖਰਾ ਹੈ। ਕੰਪੋਨੈਂਟ ਨਕਲ ਨੂੰ ਜ਼ਰੂਰੀ ਨਹੀਂ ਮੰਨਣ ਦਿੰਦੇ—ਅਤੇ ਆਖ਼ਿਰਕਾਰ, ਅਸਵੀਕਾਰਯੋਗ ਕਰ ਦਿੰਦੇ ਹਨ।
React ਤੁਹਾਨੂੰ ਉਨ੍ਹਾਂ ਹਿੱਸਿਆਂ ਦੇ ਤਰੀਕੇ ਨਾਲ UI ਡਿਜ਼ਾਈਨ ਕਰਨ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ: ਰਚਨੀਯੋਗ ਹਿੱਸਿਆਂ ਵਜੋਂ। ਇੱਕ "Checkout page" CheckoutPage ਬਣਦੀ ਹੈ ਜਿਸ ਵਿੱਚ OrderSummary, ShippingForm, ਅਤੇ PaymentMethod ਹੁੰਦੇ ਹਨ। ਹਰ ਹਿੱਸੇ ਦੀ ਸਪਸ਼ਟ ਇਨਪੁਟ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰੀ ਹੁੰਦੀ ਹੈ।
ਇਹ ਸੋਚ—ਪਹਿਲਾਂ ਕੰਪੋਨੈਂਟਾਂ ਵਿੱਚ ਸੋਚਣਾ—React ਦੇ ਫਰੰਟਐਂਡ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਬਦਲਣ ਦਾ ਇੱਕ ਵੱਡਾ ਕਾਰਣ ਸੀ। ਇਸਨੇ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਸਾਂਝੀ ਡਿਜ਼ਾਈਨ ਅਤੇ ਵਿਕਾਸ ਇਕਾਈ: ਕੰਪੋਨੈਂਟ ਦਿੱਤੀ।
React ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਮਾਨਸਿਕ ਬਦਲਾਅ ਡਿਕਲੇਰਟਿਵ UI ਹੈ: ਤੁਸੀਂ ਉਸ ਸਟੇਟ ਲਈ UI ਕਿਵੇਂ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ ਇਹ ਵਰਣਨ ਕਰਦੇ ਹੋ, ਅਤੇ React ਜਦੋਂ ਸਟੇਟ ਬਦਲਦਾ ਹੈ ਤਾਂ ਪੇਜ਼ ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ।
DOM ਨੂੰ ਮੈਨੁਅਲ ਤੌਰ 'ਤੇ ਲੱਭਣ, ਲਿਖਤ ਸੋਧਣ, ਕਲਾਸ ਟੌਗਲ ਕਰਨ ਅਤੇ DOM ਨੂੰ ਮਿਲਾਓ ਰੱਖਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ UI ਦੀ "ਸ਼ਕਲ" 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਦੇ ਹੋ। ਜਦੋਂ ਡੇਟਾ ਬਦਲਦਾ ਹੈ, UI ਮੁੜ-ਵਰਣਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ React ਘੱਟੋ-ਘੱਟ ਲੋੜੀਂਦੇ ਬਦਲਾਅ ਨਿਕਾਲਦਾ ਹੈ।
JSX ਇੱਕ ਆਸਾਨ ਤਰੀਕਾ ਹੈ ਕੰਪੋਨੈਂਟ ਡਾਂਚਾ ਲਿਖਣ ਲਈ ਜਿਸਦਾ ਸિનਟੈਕਸ JavaScript ਦੇ ਅੰਦਰ HTML ਵਰਗਾ ਦਿਖਦਾ ਹੈ। ਇਹ ਕੋਈ ਨਵਾਂ ਟੈਮਪਲੇਟਿੰਗ ਭਾਸ਼ਾ ਨਹੀਂ ਜਿਸਨੂੰ ਤੁਸੀਂ ਨੁੰਹ-ਨੂੰਹ ਸਿੱਖਣਾ ਪੈਂਦਾ; ਇਹ ਇੱਕ ਸ਼ਾਰਟਹੈਂਡ ਹੈ "ਇਹ ਕੰਪੋਨੈਂਟ ਇਹ ਦਰੱਖਤ ਰੇਂਡਰ ਕਰਦੀ ਹੈ" ਲਈ।
ਫਾਇਦਾ ਇਹ ਹੈ ਕਿ ਮਾਰਕਅੱਪ ਅਤੇ ਉਹ ਲੌਜਿਕ ਜੋ ਕਿਸ ਚੀਜ਼ ਨੂੰ ਦਿਖਾਉਣ ਦਾ ਫੈਸਲਾ ਕਰਦੀ ਹੈ, ਇਕੱਠੇ ਰਹਿੰਦੇ ਹਨ, ਜੋ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਅਲੱਗ ਤੌਰ 'ਤੇ ਸਮਝਣਾ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ।
ਇੰਪੇਰੇਟਿਵ ਕੋਡ ਉਸ ਬਾਰੇ ਦੱਸਦਾ ਹੈ ਕਿ UI ਨੂੰ ਕਿਵੇਂ ਅਪਡੇਟ ਕਰਨਾ ਹੈ ਕਦਮ-ਬਾਈ-ਕਦਮ:
// Imperative: manually keep the DOM in sync
function setLoggedIn(isLoggedIn) {
const el = document.querySelector('#status');
el.textContent = isLoggedIn ? 'Welcome back' : 'Please sign in';
el.classList.toggle('ok', isLoggedIn);
el.classList.toggle('warn', !isLoggedIn);
}
ਡਿਕਲੇਰਟਿਵ ਕੋਡ ਵਰਤਮਾਨ ਸਟੇਟ ਲਈ UI ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ 'ਤੇ ਧਿਆਨ ਕਰਦਾ ਹੈ:
function Status({ isLoggedIn }) {
return (
\u003cp className={isLoggedIn ? 'ok' : 'warn'}\u003e
{isLoggedIn ? 'Welcome back' : 'Please sign in'}
\u003c/p\u003e
);
}
ਕਿਉਂਕਿ rendering ਇੱਕ ਸ਼ੁੱਧ ਵਰਣਨ ਵਜੋਂ ਦਰਸਾਇਆ ਜਾਂਦਾ ਹੈ, ਕੰਪੋਨੈਂਟ ਆਮ ਤੌਰ 'ਤੇ ਵਧੇਰੇ ਪੜ੍ਹਨ ਯੋਗ, ਰਿਵਿਊ ਕਰਨ ਵਿੱਚ ਆਸਾਨ, ਅਤੇ ਰੀਫੈਕਟਰ ਕਰਨ ਵਿੱਚ ਸਧਾਰਨ ਹੁੰਦੇ ਹਨ। ਡਿਜ਼ਾਈਨਰ, ਪ੍ਰੋਡਕਟ-ਮਾਇਂਡਡ ਇੰਜੀਨੀਅਰ ਅਤੇ ਨਵੇਂ ਟੀਮ ਮੈਂਬਰ JSX ਨੂੰ ਅਕਸਰ ਬਿਨਾਂ ਘੁੰਮਫਿਰ ਕੇ ਸਮਝ ਲੈਂਦੇ ਹਨ।
ਇਹ ਸਾੱਫ਼ਗੀ ਸਹਿਯੋਗ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਂਦੀ ਹੈ: UI ਫੈਸਲੇ ਇੱਕ ਹੀ ਜਗ੍ਹਾ ਦਿੱਖਦੇ ਹਨ, ਅਤੇ ਬਦਲਾਅ ਹੋਰ ਜਗ੍ਹਾਂ ਤੇ ਛੁਪੇ ਸਾਈਡ-ਅੈਫੈਕਟ ਘੱਟ ਬਣਾਉਂਦੇ ਹਨ।
"ਸਟੇਟ" ਸਿਰਫ ਉਹ ਡੇਟਾ ਹੈ ਜੋ ਉਪਯੋਗਕਰਤਾ ਨਾਲ ਇੰਟਰੈਕਸ਼ਨ ਦੌਰਾਨ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲ ਸਕਦੀ ਹੈ। ਇਹ ਹੋ ਸਕਦੀ ਹੈ ਖੋਜ ਬਾਕਸ ਵਿਚ ਮੌਜ਼ੂਦ ਲਿਖਤ, ਕਿ ਮੈਨੂ ਖੁੱਲ੍ਹਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਕਾਰਟ ਦੀਆਂ ਆਈਟਮਾਂ, ਜਾਂ ਨੈੱਟਵਰਕ ਪ੍ਰਤਿਕ੍ਰਿਆ। ਜੇ ਇਹ ਬਦਲ ਸਕਦਾ ਹੈ ਅਤੇ ਸਕਰੀਨ ਨੂੰ ਇਸ ਦਾ ਪ੍ਰਭਾਵ ਦਿਖਾਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ ਇਹ ਸਟੇਟ ਹੈ।
React ਦਾ ਮੁੱਖ ਅੰਦਾਜ਼ ਇਹ ਹੈ ਕਿ rendering ਨੂੰ ਸਟੇਟ ਦਾ ਨਤੀਜਾ ਮੰਨਿਆ ਜਾਵੇ, ਨਾ ਕਿ ਮੈਨੁਅਲ DOM ਕਦਮਾਂ ਦੀ ਇੱਕ ਲੜੀ। ਤੁਸੀਂ ਉਸ ਸਟੇਟ ਲਈ UI ਦਾ ਵਰਣਨ ਕਰਦੇ ਹੋ। ਜਦੋਂ ਸਟੇਟ ਅਪਡੇਟ ਹੁੰਦਾ ਹੈ, React ਸੰਬੰਧਿਤ ਹਿੱਸਿਆਂ ਨੂੰ ਮੁੜ-ਰੈਂਡਰ ਕਰਦਾ ਹੈ।
ਇਹ ਮਾਨਸਿਕ ਮਾਡਲ "ਇਕ ਐਲਮੈਂਟ ਲੱਭੋ, ਫਿਰ ਉਸਦਾ ਟੈਕਸਟ ਅਪਡੇਟ ਕਰੋ, ਫਿਰ ਇਹ ਕਲਾਸ ਟੌਗਲ ਕਰੋ" ਤੋਂ ਵੱਖਰਾ ਹੈ। ਬਦਲਾਅ ਪਹਿਲਾਂ ਸਟੇਟ ਵਿੱਚ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਵਿਊ ਸਿਰਫ਼ ਉਸ ਸਟੇਟ ਤੋਂ ਨਿਕਲਦਾ ਹੈ।
ਇੱਕ-ਤਰੀਕਾ ਡਾਟਾ ਫਲੋ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਡੇਟਾ ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਚਲਦੀ ਹੈ:
ਇਸ ਨਾਲ ਹੈਰਾਨੀ ਘੱਟ ਹੁੰਦੀ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਅਪਡੇਟ ਦਾ ਰਸਤਾ ਪਿੱਛੇ-ਪਿੱਛੇ ਟਰੇਸ ਕਰ ਸਕਦੇ ਹੋ: ਇੱਕ ਇਵੈਂਟ ਹੁੰਦਾ, ਸਟੇਟ ਇੱਕ ਥਾਂ 'ਤੇ ਬਦਲਦਾ, ਅਤੇ UI ਉਸ ਨਵੇਂ ਸਟੇਟ ਤੋਂ ਮੁੜ-ਰੈਂਡਰ ਹੁੰਦੀ ਹੈ।
function Counter() {
const [count, setCount] = React.useState(0);
return (
\u003cdiv\u003e
\u003cp\u003eCount: {count}\u003c/p\u003e
\u003cbutton onClick={() =\u003e setCount(count + 1)}\u003eAdd\u003c/button\u003e
\u003c/div\u003e
);
}
ਇੱਥੇ, count ਸਟੇਟ ਹੈ। ਬਟਨ ਕਲਿੱਕ ਕਰਨ ਨਾਲ ਸਟੇਟ setCount ਨਾਲ ਬਦਲਦੀ ਹੈ। React ਫਿਰ ਮੁੜ-ਰੈਂਡਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਪੈਰਾ ਗ੍ਰਾਫ ਨਵਾਂ ਨੰਬਰ ਦਿਖਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਕਦੇ ਵੀ DOM ਨੂੰ ਸਿੱਧਾ "ਸੋਧ" ਨਹੀਂ ਕਰਦੇ।
ਇਹੀ ਪੈਟਰਨ ਲਿਸਟਾਂ ਫਿਲਟਰ ਕਰਨ (ਸਟੇਟ = ਫਿਲਟਰ ਟੈਕਸਟ, UI = ਫਿਲਟਰ ਕੀਤੇ ਆਈਟਮ) ਜਾਂ ਫਾਰਮ ਵੈਧਤਾ (ਸਟੇਟ = ਫੀਲਡ ਮੁੱਲ ਅਤੇ ਐਰਰ, UI = ਸੁਨੇਹੇ) ਤੱਕ ਸਕੇਲ ਕਰਦਾ ਹੈ।
React ਦਾ ਮੁੱਖ ਵਿਚਾਰ "ਪੇਜ਼ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਦੁਬਾਰਾ ਡਰਾਅ ਕਰੋ" ਨਹੀਂ ਹੈ। ਇਹ ਹੈ: UI ਨੂੰ ਸਟੇਟ ਦਾ ਨਤੀਜਾ ਮੰਨੋ, ਅਤੇ ਜਦੋਂ ਸਟੇਟ ਬਦਲੇ, ਤੁਸੀਂ ਜੋ ਹੁਣ ਚਾਹੁੰਦੇ ਹੋ ਅਤੇ ਜੋ ਪਹਿਲਾਂ ਸੀ ਦੀ ਤੁਲਨਾ ਕਰੋ—ਫਿਰ ਸਿਰਫ਼ ਉਹੀ ਅਪਡੇਟ ਕਰੋ ਜੋ ਲੋੜੀਂਦਾ ਹੈ।
ਜਦੋਂ ਕਿਸੇ ਕੰਪੋਨੈਂਟ ਦੀ ਸਟੇਟ ਜਾਂ props ਬਦਲਦੇ ਹਨ, React ਤੁਹਾਡੇ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਦੁਬਾਰਾ ਕਾਲ ਕਰਕੇ UI ਦਾ ਨਵਾਂ ਵਰਣਨ ਬਣਾਉਂਦਾ ਹੈ। ਇਸਨੂੰ ਤੁਸੀਂ ਐਸੇ ਸੋਚੋ ਜਿਵੇਂ ਦੋ ਸਨੇਪਸ਼ਾਟ:
React DOM ਨੂੰ ਸਾਫ਼ ਕਰਕੇ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਥਾਂ, ਘੱਟੋ-ਘੱਟ DOM ਆਪਰੇਸ਼ਨਾਂ ਦਾ ਸੈੱਟ ਨਿਕਾਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਜੋ A ਤੋਂ B ਤੱਕ ਲਿਜਾਏ।
"ਵਰਚੁਅਲ DOM" ਸਿਰਫ React ਦੀ ਮੇਮੋਰੀ ਵਿੱਚ ਉਪਸਥਿਤ UI ਦੀ ਪ੍ਰਤੀਨਿਧੀ ਹੈ—ਇਕ ਨਾਜ਼ੁਕ ਦਰੱਖਤ ਜੋ ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਸਕਰੀਨ 'ਤੇ ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਦੂਜਾ ਬ੍ਰਾਉਜ਼ਰ ਨਹੀਂ ਜਾਂ ਤੇਜ਼ DOM ਨਹੀਂ; ਇਹ ਇੱਕ ਡਾਟਾ ਸਰਚਨਾ ਹੈ ਜਿਸਨੂੰ React ਅਚਣਚੇਤ ਤੌਰ 'ਤੇ ਜਾਂਚ ਕੇ ਤੁਲਨਾ ਕਰ ਸਕਦਾ ਹੈ।
Reconciliation ਉਹ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜੋ ਪਿਛਲੇ virtual tree ਅਤੇ ਨਵੇਂ virtual tree ਵਿੱਚੋਂ ਕੀ ਬਦਲਿਆ ਇਹ ਪਤਾ ਲਾਉਂਦੀ ਹੈ। React ਤੇਜ਼ੀ ਨਾਲ ਇਹ ਕਰਨ ਲਈ ਕੁਝ ਹਿਊਰਿਸਟਿਕਸ ਵਰਤਦਾ ਹੈ, ਜਿਵੇਂ:
<div> <span> ਨਹੀਂ)ਜਦੋਂ React ਨੂੰ ਪਤਾ ਲੱਗ ਜਾਂਦਾ ਹੈ ਕਿ ਕੀ ਬਦਲਿਆ, ਉਹ ਸੱਚੇ DOM 'ਤੇ ਨਿਸ਼ਾਨਾ ਨਿਸ਼ਾਨਾ ਅਪਡੇਟ ਲਗਾਉਂਦਾ ਹੈ।
ਇਹ ਚੁਤਕਾ ਨਹੀਂ ਹੈ। ਪ੍ਰਦਰਸ਼ਨ ਪੈਟਰਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ: stable keys, ਬੇਕਾਰ re-renders ਤੋਂ ਬਚਣਾ, ਕੰਪੋਨੈਂਟ ਦਾ ਕੰਮ ਛੋਟਾ ਰੱਖਣਾ, ਅਤੇ rendering ਦੌਰਾਨ ਮਹਿੰਗੀ ਗਣਨਾ ਨਾ ਕਰਨਾ। React DOM ਚਰਨਾ ਘਟਾ ਸਕਦਾ ਹੈ, ਪਰ ਤੁਹਾਡੀ ਕੰਪੋਨੈਂਟ ਸਟ੍ਰਕਚਰ ਅਤੇ ਡਾਟਾ ਫਲੋ ਫਿਰ ਵੀ ਨਿਰਧਾਰਿਤ ਕਰਦੇ ਹਨ ਕਿ ਐਪ ਕਿੰਨੀ ਸਫ੍ਹਾ ਚੱਲਦੀ ਹੈ।
React ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਸਕੇਲਿੰਗ ਟ੍ਰਿਕ ਕੋਈ ਫੀਚਰ ਨਹੀਂ—ਇਹ ਕੰਪੋਜ਼ੀਸ਼ਨ ਹੈ: ਸਕਰੀਨਾਂ ਨੂੰ ਨੇਸਟਡ ਕੰਪੋਨੈਂਟਾਂ ਨਾਲ ਬਣਾਉਣਾ, props ਰਾਹੀਂ ਡੇਟਾ ਪਾਸ ਕਰਨਾ, ਅਤੇ children ਵਰਤ ਕੇ ਕੰਪੋਨੈਂਟ ਨੂੰ ਹੋਰ UI "ਲਪੇਟਣ" ਦੀ ਆਗਿਆ ਦੇਣਾ।
ਜਦੋਂ ਟੀਮਾਂ ਕੰਪੋਜ਼ੀਸ਼ਨ ਵਿੱਚ ਅਸਲੀ ਰੂਪ ਨਾਲ ਜੁੜਦੀਆਂ ਹਨ, ਉਹ ਇੱਕ-ਆਫ਼ ਪੇਜਾਂ ਦੇ ਤਰੀਕੇ ਬਾਰੇ ਸੋਚਣਾ ਬੰਦ ਕਰ ਦਿੰਦੀਆਂ ਹਨ ਅਤੇ ਛੋਟੇ, ਭਰੋਸੇਯੋਗ ਹਿੱਸਿਆਂ ਵੱਲ ਸੋਚਦੇ ਹਨ ਜੋ ਬਿਨਾਂ ਦੁਬਾਰਾ ਲਿਖੇ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਦੁਬਾਰਾ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ।
childrenਨੇਸਟਿੰਗ UI ਦੀ ਢਾਂਚਾ ਦਰਸਾਉਂਦੀ ਹੈ: ਇੱਕ ਪੇਜ ਵਿੱਚ ਸੈਕਸ਼ਨ ਹੁੰਦੇ ਹਨ, ਉਹ ਸੈਕਸ਼ਨ ਕਾਰਡ ਰੱਖਦੇ ਹਨ, ਜੋ ਕਾਰਡ ਬਟਨ ਰੱਖਦੇ ਹਨ। Props configuration ਨਾਬ ਹੈ (ਟੈਕਸਟ, ਸਟੇਟ, ਕਾਲਬੈਕ)। ਅਤੇ children ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਉਹ ਕੰਪੋਨੈਂਟ ਬਣਾਉਂਦੇ ਹੋ ਜੋ structure ਦਿੰਦਾ ਹੈ ਪਰ ਕਾਲਰ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਦਿੰਦਾ ਹੈ ਕਿ ਅੰਦਰ ਕੀ ਰੱਖਣਾ ਹੈ।
ਇੱਕ ਚੰਗਾ ਮਾਨਸਿਕ ਮਾਡਲ: props customize ਕਰਦੇ ਹਨ, children ਭਰਦੇ ਹਨ, nesting assemble ਕਰਦਾ ਹੈ।
ਲੇਆਊਟ ਕੰਪੋਨੈਂਟ ਸੰਰਚਨਾ ਅਤੇ spacing ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਨ ਬਿਨਾਂ ਬਿਜ਼ਨਸ ਲੌਜਿਕ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋਏ। ਉਦਾਹਰਣ: Page, SidebarLayout, Stack, Modal. ਇਹ ਅਕਸਰ children 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ ਤਾਂ ਜੋ ਇੱਕੋ ਲੇਆਊਟ ਵੱਖ-ਵੱਖ ਸਕਰੀਨਾਂ ਨੂੰ ਲਪੇਟ ਸਕੇ।
ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਇਨਪੁੱਟ ਫਾਰਮ ਦੇ ਵਰਤਾਰਿਆਂ ਅਤੇ ਸਟਾਈਲਿੰਗ ਨੂੰ ਸਟੈਂਡਰਡ ਕਰਦੇ ਹਨ: TextField, Select, DatePicker. ਇਹਨਾਂ ਦੇ ਨਾਲ ਲੇਬਲ, ਐਰਰ ਸਟੇਟ ਅਤੇ ਵੈਧਤਾ ਸੁਨੇਹਿਆਂ ਨੂੰ ਕੇਂਦਰਿਤ ਕੀਤਾ ਜਾਂਦਾ है ਅਤੇ ਇੱਕ ਸਧਾਰਨ prop API ਖੋਲ੍ਹੀ ਜਾਂਦੀ ਹੈ।
ਲਿਸਟ ਅਤੇ ਆਈਟਮ ਕੰਪੋਨੈਂਟ ਦੁਹਰਾਏ ਜਾਂਦੇ UI ਨੂੰ predictable ਰੱਖਦੇ ਹਨ। ਆਮ ਵਿਭਾਗ ItemList (ਫ਼ੈਚਿੰਗ, pagination, empty states) ਅਤੇ ItemRow (ਇੱਕ ਚੀਜ਼ ਕਿਵੇਂ ਲੱਗਦੀ ਹੈ) ਦਾ ਬਂਟਵਾਰਾ ਹੁੰਦਾ ਹੈ। ਇਸ ਨਾਲ rendering ਬਦਲਣ ਤੋਂ ਬਿਨਾਂ ਡੇਟਾ ਹੈਂਡਲਿੰਗ ਨੂੰ ਬਦਲਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ।
Hooks ਆਧੁਨਿਕ ਤਰੀਕਾ ਹਨ ਸਟੇਟਫੁਲ ਵਰਤਾਰੇ (ਟੌਗਲ, ਫਾਰਮ ਸਟੇਟ, ਫੈਚਿੰਗ) ਨੂੰ ਕਿਸੇ ਵੀ ਕੰਪੋਨੈਂਟ ਵਿੱਚ ਬਿਨਾਂ ਇੱਕੋ UI ਆਕਾਰ ਨੂੰ ਲੱਗੋ ਕਰਨ ਦੇ। ਇਹ ਵਿਰੋਧ ਤੀਮਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਦਿੰਦੀਆਂ ਹਨ ਜਦੋਂ ਕਿ ਲੌਜਿਕ ਇਕਸਾਰ ਰਹਿੰਦੀ ਹੈ।
ਕੰਪੋਜ਼ੀਸ਼ਨ ਹੀ ਹੈ ਜਿਸ ਨਾਲ ਡਿਜ਼ਾਈਨ ਸਿਸਟਮ ਉਪਯੋਗ ਹੋ ਕੇ ਰਹਿੰਦੇ ਹਨ: ਕੰਪੋਨੈਂਟ "ਔਥਰਾਈਜ਼ਡ" ਬਿਲਡਿੰਗ ਬਲਾਕ ਬਣ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਲੇਆਊਟ ਨਿਯਮ spacing ਅਤੇ hierarchy ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰਦੇ ਹਨ। ਜਦੋਂ ਸਿਸਟਮ ਅਪਡੇਟ ਹੁੰਦਾ—ਰੰਗ, ਟਾਇਪੋਗ੍ਰਾਫੀ, ਇੰਟਰਐਕਸ਼ਨ ਸਟੇਟ—ਉਤਪਾਦ ਘੱਟ ਮੈਨੁਅਲ ਸੋਧਾਂ ਨਾਲ ਸੁਧਾਰਾਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ।
ਸਟੇਟ ਸਿਰਫ਼ "ਬਦਲਣਯੋਗ ਡੇਟਾ" ਹੈ। React ਵਿੱਚ, ਇਸ ਸਟੇਟ ਦਾ ਸਥਾਨ ਉਸਦੇ ਵਰਤੋਂ ਤੋਂ ਜ਼ਿਆਦਾ ਅਹਮ ਹੁੰਦਾ ਹੈ।
ਲੋਕਲ ਸਟੇਟ ਇੱਕ ਕੰਪੋਨੈਂਟ (ਜਾਂ ਛੋਟੇ ਵਿਜੇਟ) ਦੀ ਮਾਲਕੀ ਹੈ ਅਤੇ ਹੋਰ ਥਾਂ ਤੋਂ ਪੜ੍ਹਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਸੋਚੋ: ਕਿ ਇੱਕ dropdown ਖੁੱਲ੍ਹਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇੱਕ ਇਨਪੁਟ ਦਾ ਮੌਜੂਦਾ ਮੁੱਲ, ਜਾਂ ਕੌਣਸਾ ਟੈਬ ਚੁਣਿਆ ਗਿਆ ਹੈ।
ਇਸ ਸਟੇਟ ਨੂੰ ਲੋਕਲ ਰੱਖਣਾ ਕੋਆਰਡੀਨੇਸ਼ਨ ਘੱਟ ਕਰਦਾ ਹੈ ਅਤੇ ਕੰਪੋਨੈਂਟਾਂ ਨੂੰ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਇੱਕ ਚੰਗਾ ਨਿਯਮ: ਜੇ ਸਿਰਫ਼ ਇੱਕ ਕੰਪੋਨੈਂਟ ਨੂੰ ਇਸ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਇਸਨੂੰ ਐਪ ਦੀ ਬਾਕੀ ਹਿੱਸੇ 'ਤਕ ਨਾ ਨਿਕਾਲੋ।
ਸਾਂਝਾ ਐਪ ਸਟੇਟ ਉਹ ਡੇਟਾ ਹੈ ਜਿਸ 'ਤੇ ਬਹੁਤ ਸਾਰੇ UI ਹਿੱਸੇ ਸਹਿਮਤ ਹੋਣਾ ਚਾਹੁੰਦੇ ਹਨ। ਆਮ ਉਦਾਹਰਣ:
ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ ਕੰਪੋਨੈਂਟ ਇੱਕੋ ਸੋਰਸ ਤੋਂ ਸਹਿਮਤ ਹੋਣਾ ਚਾਹੁੰਦੇ ਹਨ, ਸਟੇਟ ਨਕਲ ਕਰਨ ਨਾਲ mismatch ਹੁੰਦੀ ਹੈ ("header 3 ਦਿਖਾਉਂਦਾ, cart page 2").
Lift state up: ਸਟੇਟ ਨੂੰ ਨਜ਼ਦੀਕੀ ਸਾਂਝੇ ਮਾਪਾ 'ਚ ਲਿਜਾਓ ਅਤੇ props ਰਾਹੀਂ ਹੇਠਾਂ ਪਾਸ ਕਰੋ। ਇਹ ਅਕਸਰ ਸਧਾਰਨ ਵਿਕਲਪ ਹੈ ਅਤੇ ਡੇਟਾ ਫਲੋ explicit ਰੱਖਦਾ ਹੈ।
Context: ਜਦੋਂ ਬਹੁਤ ਸਾਰੇ ਕੰਪੋਨੈਂਟ ਨੂੰ ਇੱਕੋ ਮੁੱਲ ਚਾਹੀਦਾ ਹੈ ਬਿਨਾਂ prop drilling ਦੇ, ਜਿਵੇਂ ਥੀਮ ਜਾਂ auth। Context ਉਹਨਾਂ ਲਈ ਵਧੀਆ ਹੈ ਜੋ ਐਪ-ਵਿਆਪਕ ਤੇ ਅਨੁਕੂਲ ਹਨ।
External stores: ਜਦੋਂ ਸਟੇਟ ਬਹੁਤ ਜਟਿਲ ਹੋ ਜਾਂਦਾ (ਅਕਸਰ ਅਪਡੇਟ, ਦੁਰਲਭ derived data, ਪੰਨੇ-ਪੰਨੇ workflow), ਇੱਕ ਸਮਰਪਿਤ store ਤਰਕਸੰਗਤ ਤੌਰ 'ਤੇ ਤਰਕ ਸੰਜੋ ਸਕਦਾ ਹੈ।
React ਦੀ ਇੱਕ-ਤਰੀਕਾ ਡਾਟਾ ਫਲੋ ਬੇਹਤਰੀ ਨਾਲ ਕੰਮ ਕਰਦੀ ਹੈ ਜਦੋਂ ਹਰ ਪੀਸ ਦੇ ਸਟੇਟ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਮਾਲਿਕ ਹੋਵੇ। ਜਾਇਰਕਿਉ, ਇੱਕ single source of truth ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਅਤੇ ਹੋਰਾਂ ਨੂੰ ਉਸ ਤੋਂ derive ਕਰੋ (counts, totals, filtered lists) ਬਜਾਏ duplicates ਸਟੋਰ ਕਰਨ ਦੇ।
React ਦਾ ਸਭ ਤੋਂ ਵੱਡਾ ਦਿਨ-ਬ-ਦਿਨ ਫਾਇਦਾ ਕੋਈ ਚਤੁਰ rendering ਟਰਿਕ ਨਹੀਂ—ਇਹ ਕੰਪੋਨੈਂਟ ਸਰਹੱਦ ਹਨ ਜੋ UI ਕੰਮ ਨੂੰ ਛੋਟੇ, ਸੁਰੱਖਿਅਤ ਬਦਲਾਅ ਵਿੱਚ ਤਬਦੀਲ ਕਰ ਦਿੰਦੇ ਹਨ। ਜਦੋਂ ਇੱਕ ਕੰਪੋਨੈਂਟ ਦੀ ਸਪਸ਼ਟ ਜ਼ਿੰਮੇਵਾਰੀ ਅਤੇ ਇੱਕ ਸਥਿਰ public "ਸਰਫੇਸ" (ਇਸਦੇ props) ਹੁੰਦੀ ਹੈ, ਟੀਮਾਂ internals ਨੂੰ ਰੀਫੈਕਟਰ ਕਰ ਸਕਦੀਆਂ ਹਨ ਬਿਨਾਂ ਐਪ-ਭਰ ਦੇ ਰੀ-ਰਾਈਟ ਦੀ ਲੋੜ ਪਏ। ਇਹ ਸਥਿਰਤਾ ਕੋਡ ਰਿਵਿਊਜ਼ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦੀ, ਗਲਤਫਹਿਮੀਆਂ ਘਟਾਉਂਦੀ, ਅਤੇ ਨਵੇਂ ਮੈਂਬਰਾਂ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰਦੀ ਹੈ ਕਿ ਕਿੱਥੇ ਬਦਲਾਅ ਕਰਨੇ ਹਨ।
ਇੱਕ ਉਪਯੋਗੀ ਮਾਨਸਿਕ ਮਾਡਲ ਇਹ ਹੈ: ਦਿੱਤੇ props ਅਤੇ ਸਟੇਟ ਦੇ ਨਾਲ, ਇੱਕ ਕੰਪੋਨੈਂਟ ਪੇਸ਼ਗੀ ਤੌਰ 'ਤੇ UI ਦਾ ਵਰਣਨ ਕਰੇ। ਭਾਵੇਂ ਪ੍ਰਭਾਵ ਅਤੇ ਬ੍ਰਾਉਜ਼ਰ APIs ਮੌਜੂਦ ਹਨ, ਬਹੁਤ ਸਾਰੇ ਕੰਪੋਨੈਂਟ ਲੌਜਿਕ deterministic ਰਹਿ ਸਕਦੇ ਹਨ। ਇਸੀ ਲਈ maintainable React ਟੈਸਟਿੰਗ ਅਕਸਰ ਵਿਹਾਰ ਅਤੇ ਆਉਟਪੁੱਟ 'ਤੇ ਕੇਂਦਰਿਤ ਹੁੰਦੀ ਹੈ:
Accessibility checks ਇੱਥੇ ਸਹਜ ਫਿੱਟ ਹੋ ਜਾਂਦੇ ਹਨ: ਜੇ ਤੁਸੀਂ roles ਅਤੇ accessible names ਨਾਲ ਟੈਸਟ ਕਰਦੇ ਹੋ, ਤੁਸੀਂ ਗੁੰਮਸ਼ੁਦਾ ਲੇਬਲ, ਟੁੱਟੇ ਫੋਕਸ ਸੂਤਰ, ਅਤੇ ਗੈਰ-ਅਨੁਕੂਲ semantics ਜਲਦੀ ਪਤਾ ਲਾ ਸਕਦੇ ਹੋ। consistency checks (linting, formatting, design-system ਵਰਤੋਂ) ਉਸੇ ਵਿਚਾਰ ਨੂੰ ਮਜ਼ਬੂਤ ਕਰਦੇ ਹਨ: predictable components ਅਸਾਨੀ ਨਾਲ ਰੱਖ-ਰੱਖਾਵ ਯੋਗ ਹੁੰਦੇ ਹਨ।
ਜਦੋਂ ਕੰਪੋਨੈਂਟ ਇੱਕ ਛੋਟੀ prop API ਖੋਲ੍ਹਦੇ ਹਨ ਅਤੇ implementation details ਨੂੰ ਛੁਪਾਉਂਦੇ ਹਨ, ਕਈ ਲੋਕ ਇਕੱਠੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹਨ—ਇੱਕ styling ਨੂੰ ਤਬਦੀਲ ਕਰਦਾ, ਦੂਜਾ data fetching ਬਦਲਦਾ, ਤੀਜਾ ਟੈਸਟ ਅਪਡੇਟ ਕਰਦਾ—ਬਿਨਾਂ ਇੱਕ ਦੂਜੇ ਨਾਲ ਟਕਰਾਉਂਦੇ।
React ਪ੍ਰਦਰਸ਼ਨ ਆਮ ਤੌਰ 'ਤੇ ਇੱਥੇ ਨਹੀਂ ਹੈ ਕਿ "React ਹਮੇਸ਼ਾਂ ਹੌਲੀ ਹੈ", ਸਗੋਂ ਇਹ ਕਿ ਤੁਹਾਡੀ ਐਪ ਬਰਾਊਜ਼ਰ ਨੂੰ ਕਿੰਨਾ ਕੰਮ ਕਰਵਾ ਰਹੀ ਹੈ। ਸਭ ਤੋਂ ਤੇਜ਼ UI ਉਹ ਹੈ ਜੋ ਘੱਟ ਕਰਦਾ ਹੈ: ਘੱਟ DOM nodes, ਘੱਟ layout/reflow, ਘੱਟ ਮਹਿੰਗੀਆਂ ਗਣਨਾਵਾਂ, ਅਤੇ ਘੱਟ ਨੈੱਟਵਰਕ ਰਿਕਵੈਸਟ।
ਇੱਕ ਆਮ ਸਮੱਸਿਆ ਬੇਕਾਰ re-renders ਹੁੰਦੀ ਹੈ: ਇੱਕ ਛੋਟੀ ਸਟੇਟ ਬਦਲਾਅ ਇੱਕ ਵੱਡੇ subtree ਨੂੰ ਮੁੜ-ਰੈਂਡਰ ਕਰਵਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਸਟੇਟ ਬਹੁਤ ਉੱਚayi ਹੈ, ਜਾਂ props ਹਰੇਕ ਵਾਰੀ identity ਬਦਲ ਰਹੀ ਹੈ (ਨਵੇਂ objects/functions inline ਬਣਾਏ ਜਾ ਰਹੇ ਹਨ)।
ਹੋਰ pain point ਭਾਰੀ ਲਿਸਟਾਂ ਹਨ—ਸੈਂਕੜੇ ਜਾਂ ਹਜ਼ਾਰਾਂ ਰੋਜ਼ जिन੍ਹਾ ਵਿੱਚ ਚਿੱਤਰ, ਫਾਰਮੈਟਿੰਗ, ਅਤੇ ਇਵੈਂਟ ਹੈਂਡਲਰ ਹੁੰਦੇ ਹਨ। ਭਾਵੇਂ ਹਰ ਰੋ "ਸਸਤਾ" ਹੋਵੇ, ਕੁੱਲ ਕੰਮ ਜ਼ਿਆਦਾ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਕ੍ਰੋਲਿੰਗ ਰੁਕावट ਭਰ ਜਾਣਦੀ ਹੈ।
ਢਾਂਚੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ:
ਇਸ ਤੋਂ ਇਲਾਵਾ ਉਨ੍ਹਾਂ ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਉਪਭੋਗਤਾ ਮਹਿਸੂਸ ਕਰਦਾ ਹੈ: input lag ਘਟਾਓ, ਪਹਿਲੀ ਮਹੱਤਵਪੂਰਨ ਪੇਂਟ ਤੇਜ਼ ਕਰੋ, ਅਤੇ ਇੰਟਰਐਕਸ਼ਨ ਨੂੰ ਨਰਮ ਰੱਖੋ। ਐਕ ਵਾਰ-ਬਾਰ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਇੰਟਰਐਕਸ਼ਨ ਵਿੱਚ 20ms ਸੁਧਾਰ ਇੱਕ ਘਟਨਾ ਵਿੱਚ 200ms ਬਚਤ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਅਹਮ ਹੋ ਸਕਦਾ ਹੈ।
Derived state ਉਹ ਡੇਟਾ ਹੈ ਜੋ ਤੁਸੀਂ ਹੋਰ ਸਟੇਟ/props ਤੋਂ ਕਮਪਿਊਟ ਕਰ ਸਕਦੇ ਹੋ (ਜਿਵੇਂ fullName = firstName + lastName, ਜਾਂ filtered items ਇੱਕ ਲਿਸਟ + query ਤੋਂ). ਇਸਨੂੰ ਸਟੋਰ ਕਰਨ ਨਾਲ ਅਕਸਰ ਬਗ ਆਉਂਦੇ ਹਨ: ਹੁਣ ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਸੋਰਸ ਆਫ਼ ਥਰੁਥ ਹਨ ਜੋ drift ਕਰ ਸਕਦੇ ਹਨ।
ਪਸੰਦ ਕਰੋ ਕਿ derived ਮੁੱਲ rendering ਦੌਰਾਨ ਕਮਪਿਊਟ ਕੀਤੇ ਜਾਣ ਤਾਂ ਜੋ ਡੁਪਲੀਕੇਟ ਸਟੋਰ ਨਾ ਹੋਵੇ—ਜੇਕਰ ਮਹਿੰਗਾ ਹੈ ਤਾਂ memoize ਕਰੋ। ਸਿਰਫ਼ ਉਹੀ ਸਟੋਰ ਕਰੋ ਜੋ derive ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ—ਆਮ ਤੌਰ 'ਤੇ ਯੂਜ਼ਰ ਇਨਪੁਟ, ਸਰਵਰ ਜਵਾਬ, ਅਤੇ UI ਇਰਾਦੇ (ਜਿਵੇਂ "panel ਖੁੱਲ੍ਹਾ ਹੈ?")।
React ਸਿਰਫ਼ UI ਲਿਖਣ ਦਾ ਇੱਕ ਸੋਹਣਾ ਤਰੀਕਾ ਨਹੀਂ ਲਿਆ; ਇਸਨੇ ਟੀਮਾਂ ਨੂੰ ਇਹ ਦਿਸ਼ਾ ਦਿੱਤੀ ਕਿ ਫਰੰਟਐਂਡ ਕਿਵੇਂ ਬਣਾਇਆ, ਸਾਂਝਾ, ਅਤੇ ਰੱਖਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਕੰਪੋਨੈਂਟ ਪਹਿਲਾਂ ਡਿਫੌਲਟ ਮਾਨਸਿਕ ਮਾਡਲ ਨਾ ਹੋਣ 'ਤੇ, ਬਹੁਤ ਪ੍ਰੋਜੈਕਟ UI ਨੂੰ ਪੇਜਾਂ ਅਤੇ ਵਿਖਰੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਵਜੋਂ ਦੇਖਦੇ ਸਨ। React ਨਾਲ, ਆਰਕੀਟੈਕਚਰ ਦੀ ਇਕਾਈ ਅਕਸਰ ਕੰਪੋਨੈਂਟ ਬਣ ਗਈ: ਇੱਕ UI ਹਿੱਸਾ ਜਿਸਦੀ ਸਪਸ਼ਟ API (props) ਅਤੇ predictable ਵਰਤਾਰਾ ਹੁੰਦਾ ਹੈ।
React SPA (Single-Page Application) ਦੇ ਉਥੇ ਉਭਾਰ ਨਾਲ ਠੀਕ ਫਿੱਟ ਬੈਠਿਆ। ਜਦੋਂ rendering ਸਟੇਟ ਤੋਂ ਚਲਦੀ ਹੈ, "ਪੇਜ਼" ਸਰਵਰ-ਪਹਿਲਾਂ ਟੈਂਪਲੇਟ ਰਿਹਾ ਨਾ ਰਹਿ ਕੇ ਕੰਪੋਨੈਂਟਾਂ ਅਤੇ ਕਲਾਇਂਟ-ਸਾਈਡ ਰਾਊਟਿੰਗ ਦੀ ਰਚਨਾ ਬਣ ਗਿਆ। ਇਸ ਬਦਲਾਅ ਨਾਲ ਕੋਡ ਨੂੰ ਫੀਚਰ ਖੇਤਰਾਂ ਅਤੇ ਦੁਹਰਾਏ ਯੂਆਈ ਭਾਗਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਬਣਾਉਣਾ ਆਮ ਹੋ ਗਿਆ—ਅਲੱਗ HTML ਫਾਇਲਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਨਹੀਂ।
ਜਿਵੇਂ ਹੀ UI ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲੇ ਹਿੱਸਿਆਂ ਤੋਂ ਬਣਿਆ, ਇਸਨੂੰ ਸਟੈਂਡਰਡ ਕਰਨਾ ਆਮ ਹੋ ਗਿਆ। ਕਈ ਸੰਗਠਨਾਂ ਨੇ ਕਾਪੀ‑ਪੇਸਟ ਮਾਰਕਅੱਪ ਨੂੰ ਛੱਡ ਕੇ ਕੰਪੋਨੈਂਟ ਲਾਇਬ੍ਰੇਰੀਆਂ ਬਣਾਈਆਂ: ਬਟਨ, ਫਾਰਮ ਕੰਟਰੋਲ, ਮੋਡਲ, ਲੇਆਊਟ ਪ੍ਰਿਮਿਟਿਵ, ਅਤੇ ਪੈਟਰਨ ਜਿਵੇਂ empty states। ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਕਸਰ ਡਿਜ਼ਾਈਨ ਸਿਸਟਮਾਂ ਵਿੱਚ ਵਿਕਸਤ ਹੋ ਗਈਆਂ—ਸਾਂਝੇ ਕੰਪੋਨੈਂਟਾਂ ਅਤੇ ਦਸਤਾ ਵੇ-ਨਿਰਦੇਸ਼ਾਂ ਨਾਲ—ਤਾਂ ਜੋ ਟੀਮਾਂ ਬਿਨਾਂ ਹਰ ਸਕਰੀਨ ਲਈ UI ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੇ ਇੱਕਸਾਰ ਅਨੁਭਵ ਭੇਜ ਸਕਣ।
ਕੰਪੋਨੈਂਟਾਂ ਨੇ ਟੀਮਾਂ ਨੂੰ ਗੱਲ-ਬਾਤ ਇਕੋ ਹੀ ਨਾਮਾਂ ਨਾਲ ਕਰਨ ਲਈ ਪ੍ਰੇਰਿਤ ਕੀਤਾ। ਜਦੋਂ ਹਰ ਕੋਈ \u003cButton\u003e, \u003cTooltip\u003e, ਜਾਂ \u003cCheckoutSummary\u003e ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਹੈ, ਗੱਲ-ਬਾਤ ਵੱਧ ਠੋਸ ਹੋ ਜਾਂਦੀ ਹੈ: ਲੋਕ ਵਿਵਹਾਰ ਅਤੇ ਸਰਹੱਦਾਂ ਬਾਰੇ ਚਰਚਾ ਕਰ ਸਕਦੇ ਹਨ, ਸਿਰਫ਼ ਦ੍ਰਿਸ਼ ਦਿਖਾਵਟ ਬਾਰੇ ਨਹੀਂ। ਇਹ ਸਾਂਝਾ ਵਾਕਭੰਡਾਰ ਨਵੇਂ ਮੈਂਬਰਾਂ ਨੂੰ ਕੋਡ 'ਚ ਦਾਜ਼-ਖੋਜ ਕਰਨ ਵਿੱਚ ਵੀ ਤੇਜ਼ੀ ਲਿਆਉਂਦਾ ਹੈ।
React ਦੀ ਕਾਮਯਾਬੀ ਨੇ ਬ੍ਰੋਡਰ ਫਰੰਟਐਂਡ ਕਮਿਊਨਿਟੀ ਨੂੰ ਇਹ ਸੋਚਣ ਲਈ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ: ਕੰਪੋਨੈਂਟ-ਪਹਿਲਾਂ ਵਿਕਾਸ, ਡਿਕਲੇਰਟਿਵ ਰੈਂਡਰਿੰਗ, ਅਤੇ predictable ਡਾਟਾ ਫਲੋ ਹੁਣ ਆਮ ਉਮੀਦਾਂ ਬਣ ਗਈਆਂ। ਹੋਰ ਫਰੇਮਵਰਕਾਂ ਨੇ ਵੀ ਇੱਕੋ ਜਿਹਾ ਵਿਚਾਰ ਘਿਰਿਆ, ਭਾਵੇਂ ਇੰਪਲੇਮੈਂਟੇਸ਼ਨ ਵੱਖਰੇ ਹੋਣ, ਕਿਉਂਕਿ ਇਹ ਪ੍ਰੈਕਟਿਸਜ਼ ਵਾਸਤਵ ਵਿੱਚ ਵੱਡੀਆਂ ਟੀਮਾਂ ਵਿੱਚ ਸਕੇਲ ਕਰਨ ਲਈ ਸਹੂਲਤਵਾਂ ਦਿੰਦੀਆਂ ਹਨ।
React ਨੇ ਉਹ ਸਿੱਧਾਂਤ ਲਿਆ ਕੇ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਆਸਾਨ ਕੀਤਾ, ਪਰ ਇਹ ਮੁਫ਼ਤ ਨਹੀਂ। ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਟਰੇਡ‑ਆਫ਼ ਜਾਣਨਾ ਟੀਮਾਂ ਨੂੰ ਇਹ ਚੁਣਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿ ਕਦੋਂ React ਜ਼ੁਰੂਰੀ ਹੈ—ਅਤੇ cargo-cult ਅਪ੍ਰੋਚ ਤੋਂ ਬਚਦਾ ਹੈ।
React ਦੀ ਸਿੱਖਣੀ ਵਕਫ਼ਤ ਹੈ: ਕੰਪੋਨੈਂਟ, hooks, ਅਤੇ ਮਨੋਵੈज्ञानिक ਮਾਡਲ ਜਿਵੇਂ ਸਟੇਟ ਅਪਡੇਟ ਅਤੇ ਪ੍ਰਭਾਵ ਸਮਝਣ ਲਈ ਸਮਾਂ ਲੱਗਦਾ ਹੈ। ਆਧੁਨਿਕ React ਅਕਸਰ build tooling (bundling, linting, TypeScript ਵਿਕਲਪਿਕ) ਮੰਗਦਾ ਹੈ, ਜੋ ਸੈਟਅਪ ਅਤੇ ਰੱਖ-ਰੱਖਾਵ ਜੋੜਦਾ ਹੈ। ਆਖ਼ਰਕਾਰ, React abstraction ਦੀਆਂ ਪਰਤਾਂ ਲਿਆਉਂਦਾ ਹੈ—ਕੰਪੋਨੈਂਟ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਰਾਊਟਿੰਗ, ਡਾਟਾ ਫੈਚਿੰਗ ਪੈਟਰਨ—ਜੋ ਮਦਦਗਾਰ ਹੋ ਸਕਦੇ ਹਨ, ਪਰ ਜਦ ਤੱਕ ਕੁਝ ਟੁੱਟਦਾ ਨਹੀਂ ਇਹ ਦਿਖਾਉਂਦੇ ਨਹੀਂ।
“React ਸਿਰਫ਼ view ਹੈ.” ਸਿਧਾਂਤਕ ਰੂਪ ਵਿੱਚ ਹਾਂ; ਪ੍ਰਯੋਗਿਕ ਰੂਪ ਵਿੱਚ, React ਤੁਹਾਡੀ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਕਾਫੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਕੰਪੋਨੈਂਟ ਸਰਹੱਦ, ਸਟੇਟ ਮਾਲਕੀ, ਅਤੇ ਕੰਪੋਜ਼ੀਸ਼ਨ ਪੈਟਰਨ ਡੇਟਾ ਫਲੋ ਅਤੇ ਕੋਡ ਅੰਗ੍ਰੇਜ਼ੀ 'ਤੇ ਅਸਰ ਪਾਂਦੇ ਹਨ।
“ਵਰਚੁਅਲ DOM ਹਰ ਵਾਰੀ ਤੇਜ਼ ਹੈ.” ਵਰਚੁਅਲ DOM ਮੁੱਖ ਤੌਰ 'ਤੇ predictable updates ਅਤੇ ਡਿਵੈਲਪਰ ਸੁਵਿਧਾ ਬਾਰੇ ਹੈ। React ਤੇਜ਼ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਪ੍ਰਦਰਸ਼ਨ rendering ਪੈਟਰਨ, memoization, ਲਿਸਟ ਸਾਈਜ਼, ਅਤੇ unnecessary re-renders 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ।
React ਉਹ ਐਪਲਿਕੇਸ਼ਨਾਂ ਲਈ ਚੰਗਾ ਹੈ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਬਹੁਤ ਸਾਰਾ ਇੰਟਰਐਕਟਿਵ ਸਟੇਟ, ਲੰਬੇ-ਜੀਵਨ ਕੋਡਬੇਸ, ਅਤੇ ਕਈ ਵਿਕਾਸਕਾਰ ਇਕੱਠੇ ਕੰਮ ਕਰਦੇ ਹਨ। ਇੱਕ ਮੁੱਖ ਤੌਰ 'ਤੇ ਸਟੈਟਿਕ ਮਾਰਕੀਟਿੰਗ ਸਾਈਟ ਜਾਂ ਕੁਝ ਛੋਟੇ ਵਿਜੇਟਾਂ ਲਈ, ਸਰਵਰ-ਰੈਂਡਰਡ ਟੈਂਪਲੇਟ, ਹਲਕੇ JS, ਜਾਂ ਮਿਨੀਮਲ ਫਰੇਮਵਰਕ ਜ਼ਿਆਦਾ ਆਸਾਨ ਅਤੇ ਘੱਟ ਰੱਖ-ਰੱਖਾਵ ਵਾਲੇ ਵਿਕਲਪ ਹੋ ਸਕਦੇ ਹਨ।
ਜੇ ਤੁਸੀਂ ਇੱਕ React ਐਪ ਦੀ ਪ੍ਰੋਟੋਟਾਈਪਿੰਗ ਕਰ ਰਹੇ ਹੋ ਅਤੇ ਇਹ ਵਿਚਾਰ ਤੇਜ਼ੀ ਨਾਲ ਸਪੱਸ਼ਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ (ਕੰਪੋਨੈਂਟ ਸਰਹੱਦ, ਸਟੇਟ ਮਾਲਕੀ, ਕੰਪੋਜ਼ੀਸ਼ਨ ਪੈਟਰਨ), ਤਾਂ ਇੱਕ vibe-coding ਵਰਕਫਲੋ ਤੇਜ਼ੇ ਨਾਲ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ। ਉਦਾਹਰਣ ਲਈ, Koder.ai ਤੁਹਾਨੂੰ ਚੈਟ ਵਿੱਚ ਫੀਚਰ ਵੇਰਵਾ ਦੱਸ ਕੇ ਇੱਕ ਕੰਮ ਕਰ ਰਹੀ React ਫਰੰਟਐਂਡ ਨਾਲ Go/PostgreSQL ਬੈਕਐਂਡ ਜੈਨਰੇਟ ਕਰਨ ਦਿੰਦਾ ਹੈ, ਫਿਰ snapshots/rollback ਨਾਲ ਇੰਟਰਏਟ ਕਰਨ ਅਤੇ ਤਿਆਰ ਹੋਣ ਤੇ ਸੋਸ ਕੋਡ ਐਕਸਪੋਰਟ ਕਰਨ ਦਿੰਦਾ ਹੈ। ਇਹ ਰੀਅਲ ਫੀਚਰ 'ਤੇ ਆਰਕੀਟੈਕਚਰ ਫੈਸਲੇ ਨੂੰ ਤਜੇਬੀ ਤੌਰ 'ਤੇ ਜਾਂਚਣ ਦਾ ਇੱਕ ਪ੍ਰਯੋਗਿਕ ਤਰੀਕਾ ਹੈ।
ਅਗਲਾ ਕਦਮ: ਇੱਕ ਅਸਲੀ ਫੀਚਰ ਦਾ ਪ੍ਰੋਟੋਟਾਈਪ ਬਣਾਓ, ਜਟਿਲਤਾ ਅਤੇ ਟੀਮ ਵੈਲੋਸਿਟੀ ਨਾਪੋ, ਫਿਰ ਪੈਟਰਨ ਨੂੰ ਸੋਚ-ਸਮਝ ਕੇ ਸਕੇਲ ਕਰੋ—ਬਿਨਾਂ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਨਹੀਂ।
Jordan Walke ਨੇ Facebook ਵਿੱਚ ਕੰਮ ਕਰਦਿਆਂ React ਬਣਾਈ। React ਮਹੱਤਵਪੂਰਨ ਇਸ ਲਈ ਸੀ ਕਿਉਂਕਿ ਇਸ ਨੇ ਨਾਜ਼ੁਕ, ਮੈਨੂਅਲ DOM “ਗਲੂ ਕੋਡ” ਨੂੰ ਕੰਪੋਨੈਂਟ-ਅਧਾਰਿਤ, ਸਟੇਟ-ਡ੍ਰਿਵਨ ਤਰੀਕੇ ਨਾਲ ਬਦਲ ਦਿੱਤਾ—ਜਿਸ ਨਾਲ ਜਟਿਲ ਇੰਟਰਫੇਸ ਸਹੀ ਤਰ੍ਹਾਂ ਸਕੇਲ, ਡੀਬੱਗ ਅਤੇ ਰੱਖ-ਰੱਖਾਵ ਹੋ ਸਕਦੇ ਹਨ।
ਟੈਂਪਲੇਟ-ਅਤੇ-jQuery ਸ਼ੈਲੀ ਦੇ ਫਰੰਟਐਂਡ ਵਿੱਚ UI ਨਿਯਮ ਮਾਰਕਅੱਪ ਅਤੇ ਵਿੱਖਰੀਆਂ ਇਵੈਂਟ ਹੈਂਡਲਰਾਂ ਵਿੱਚ ਫੈਲ ਜਾਂਦੇ ਸਨ ("ਜੇ X ਹੁੰਦਾ ਹੈ ਤਾਂ Y ਅਪਡੇਟ ਕਰੋ"). ਕੰਪੋਨੈਂਟ UI ਅਤੇ ਲੌਜਿਕ ਨੂੰ ਇੱਕ ਛੋਟੀ ਇੰਟਰਫੇਸ (props) ਦੇ ਪਿੱਛੇ ਬੰਦ ਕਰਦੇ ਹਨ, ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਪੇਜ਼ਾਂ ਨੂੰ ਪੈਚ ਕਰਨ ਦੀ ਬਜਾਏ ਭਰੋਸੇਮੰਦ ਟੁਕੜਿਆਂ ਤੋਂ ਫੀਚਰ ਬਣਾਉ।
ਕੰਪੋਨੈਂਟ ਇੱਕ ਦੁਹਰਾਏ ਜਾ ਸਕਣ ਵਾਲਾ ਯੂਨਿਟ ਹੁੰਦਾ ਹੈ ਜੋ ਇਨਪੁਟ (ਅਕਸਰ props) ਲੈਂਦਾ ਹੈ ਅਤੇ ਉਨ੍ਹਾਂ ਇਨਪੁਟਸ ਲਈ UI ਕਿਵੇਂ ਦਿਖਣਾ ਚਾਹੀਦਾ ਹੈ ਇਹ ਵਾਪਸ ਕਰਦਾ ਹੈ।
ਤੁਹਾਡੇ ਲਈ ਅਮਲੀ ਨਿਯਮ:
Props ਉਹ ਇਨਪੁਟ ਹਨ ਜੋ ਤੁਸੀਂ ਕਿਸੇ ਕੰਪੋਨੈਂਟ ਵਿੱਚ ਦਿੰਦੇ ਹੋ ਤਾਂ ਜੋ ਉਹ ਕਨਫ਼ਿਗਰ ਹੋ ਸਕੇ (ਟੈਕਸਟ, ਫਲੈਗ, کالਬੈਕ, ਜਾਂ ਹੋਰ UI). Props ਨੂੰ ਇੱਕ ਠੋਸ ਕਾਂਟਰੈਕਟ ਵਾਂਗ ਸੋਚੋ:
disabled, onSubmit) ਥਾਂ vague ਹੋਣ ਦੇਡਿਕਲੇਰਟਿਵ UI ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਵਰਤਮਾਨ ਸਟੇਟ ਲਈ UI ਕੀ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਇਹ ਵਰਣਨ ਕਰਦੇ ਹੋ, ਨਾ ਕਿ DOM ਨੂੰ ਕਿਵੇਂ ਅਪਡੇਟ ਕਰਨਾ ਹੈ ਉਸਦੇ ਕਦਮ-ਬਾਈ-ਕਦਮ ਜਾਣਕਾਰੀ।
ਪ੍ਰਯੋਗਿਕ ਤੌਰ 'ਤੇ:
JSX ਇੱਕ ਸਿੰਟੈਕਸ ਹੈ ਜੋ ਤੁਹਾਨੂੰ JavaScript ਦੇ ਅੰਦਰ HTML ਵਰਗੀ ਢਾਂਚਾ ਲਿਖਣ ਦੀ ਆਸਾਨੀ ਦਿੰਦਾ ਹੈ। ਇਹ ਲਾਭਕਾਰੀ ਹੈ ਕਿਉਂਕਿ ਰੈਨਡਰਿੰਗ ਲੌਜਿਕ ਅਤੇ ਮਾਰਕਅੱਪ ਇਕੱਠੇ ਰਹਿੰਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਕੰਪੋਨੈਂਟ ਇੱਕ ਇਕਾਈ ਵਜੋਂ ਪੜ੍ਹਨ ਤੇ ਸਮਝਣ ਵਿੱਚ ਆਸਾਨ ਹੁੰਦੇ ਹਨ।
ਸਟੇਟ ਉਹ ਕੋਈ ਵੀ ਡੇਟਾ ਹੈ ਜੋ ਸਮੇਂ ਦੇ ਨਾਲ ਬਦਲ ਸਕਦੀ ਹੈ ਅਤੇ ਜਿਸ ਤੋਂ ਸਕਰੀਨ ਪ੍ਰਭਾਵਿਤ ਹੁੰਦੀ ਹੈ (ਇਨਪੁਟ ਟੈਕਸਟ, ਲੋਡਿੰਗ ਸਥਿਤੀ, ਕਾਰਟ ਦੀਆਂ ਆਈਟਮਾਂ ਆਦਿ).
ਵਿਆਹਿਕ ਨਿਯਮ: ਸੱਚਾਈ ਦਾ ਸੋਰਸ (ਯੂਜ਼ਰ ਇਨਪੁਟ, ਸਰਵਰ ਜਵਾਬ, UI ਉਦੇਸ਼) ਸਟੋਰ ਕਰੋ, ਅਤੇ ਹੋਰ ਸਾਰੇ ਮੁੱਲ (ਗਿਣਤੀਆਂ, ਫਿਲਟਰ ਕੀਤੇ ਆਈਟਮ) ਉਨ੍ਹਾਂ ਤੋਂ ਨਿਕਾਲੋ।
ਇੱਕ-ਤਰੀਕਾ ਡਾਟਾ ਫਲੋ ਦਾ ਮਤਲਬ ਹੈ:
ਇਸ ਨਾਲ ਡੀਬੱਗ ਕਰਨਾ ਆਸਾਨ ਬਣਦਾ ਹੈ ਕਿਉਂਕਿ ਅਪਡੇਟ ਦਾ ਰਸਤਾ ਸਿੱਧਾ ਹੁੰਦਾ ਹੈ: ਇਵੈਂਟ → ਸਟੇਟ ਬਦਲਾਅ → ਰੀ-ਰੈਂਡਰ।
ਵਰਚੁਅਲ DOM React ਦੀ ਇਨ-ਮੇਮੋਰੀ ਪ੍ਰਤੀਕਿਰਤੀ ਹੈ। ਜਦੋਂ ਸਟੇਟ/props ਬਦਲਦੇ ਹਨ, React ਪਿਛਲੇ UI ਵਰਣਨ ਨੂੰ ਨਵੇਂ ਨਾਲ ਤੁਲਨਾ ਕਰਦਾ ਹੈ ਅਤੇ ਸਚੇ DOM ਨੂੰ ਸਿਰਫ਼ ਜਿੱਥੇ ਲੋੜ ਹੈ ਉੱਥੇ ਅਪਡੇਟ ਕਰਦਾ ਹੈ।
ਆਮ ਤੌਰ 'ਤੇ ਧਿਆਨ ਰੱਖੋ:
key ਵਰਤੋਸ਼ੁਰੂਆਤ ਸਧਾਰਣ ਰੱਖੋ ਅਤੇ ਜਰੂਰਤ ਪੈਣ 'ਤੇ ਹੀ ਬਾਹਰ ਵਧੋ:
ਇੱਕ ਸਿੰਗਲ source of truth ਵੱਲ ਪ੍ਰਾਥਮਿਕਤਾ ਦਿਓ ਅਤੇ ਹੋਰਾਂ ਨੂੰ ਦਰਜ ਵਿਚੋਂ ਕਮਪਿਊਟ ਕਰੋ ਤਾਂ ਕਿ mismatch ਨਾ ਹੋਵੇ।