React ਨੇ component-ਅਧਾਰਿਤ UI, declarative rendering, ਅਤੇ state-driven views ਨੂੰ ਆਮ ਕੀਤਾ—ਟੀਮਾਂ ਨੂੰ page-ਕੇਂਦ੍ਰਿਤ ਕੋਡ ਤੋਂ ਮੁੜ-ਉਪਯੋਗ ਸਿਸਟਮਾਂ ਅਤੇ ਪੈਟਰਨਾਂ ਵੱਲ ਲਿਜਾ ਕੇ।

React ਸਿਰਫ਼ ਇੱਕ ਨਵਾਂ ਲਾਇਬਰੇਰੀ ਨਹੀਂ ਲਿਆਉਂਦਾ—ਇਸ ਨੇ ਇਹ ਬਦਲ ਦਿੱਤਾ ਕਿ ਟੀਮਾਂ “frontend architecture” ਨਾਲ ਕੀ ਮਤਲਬ ਮੰਨਦੀਆਂ ਹਨ। ਅਮਲ ਵਿੱਚ, frontend architecture ਉਹ ਫੈਸਲੇ ਹਨ ਜੋ UI ਕੋਡਬੇਸ ਨੂੰ ਸਕੇਲ 'ਤੇ ਸਮਝਣਯੋਗ ਰੱਖਦੇ ਹਨ: ਤੁਸੀਂ UI ਨੂੰ ਕਿਵੇਂ ਭਾਗਾਂ ਵਿੱਚ ਵੰਡਦੇ ਹੋ, ਡੇਟਾ ਉਹਨਾਂ ਵਿੱਚ ਕਿਵੇਂ ਜਾਂਦੀ ਹੈ, state ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ, side effects (ਜਿਵੇਂ ਡੇਟਾ ਫੈਚ ਕਰਨਾ) ਕਿਵੇਂ ਹੇਠਾਂ ਲਿਆਂਦੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਟੀਮ-ਵਿਚਾਰਯੋਗ ਅਤੇ ਟੈਸਟੇਬਲ ਕਿਵੇਂ ਰੱਖਦੇ ਹੋ।
Component thinking ਹਰ UI ਹਿੱਸੇ ਨੂੰ ਇੱਕ ਛੋਟੀ, ਮੁੜ-ਉਪਯੋਗ ਯੂਨਿਟ ਵਜੋਂ ਦੇਖਣਾ ਹੈ ਜੋ ਆਪਣੀ rendering ਦਾ ਮਾਲਕ ਹੈ ਅਤੇ ਹੋਰ ਯੂਨਿਟਾਂ ਨਾਲ ਜੋੜ ਕੇ ਪੂਰੇ ਪੇਜ਼ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
React ਦੇ ਮਸ਼ਹੂਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਬਹੁਤ ਪ੍ਰੋਜੈਕਟ ਪੇਜ਼ ਅਤੇ DOM ਮੈਨਿਪੂਲੇਸ਼ਨ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸੰਗਠਿਤ ਹੁੰਦੇ ਸਨ: “ਇਸ ਐਲੀਮੈਂਟ ਨੂੰ ਲੱਭੋ, ਇਸ ਦਾ ਟੈਕਸਟ ਬਦਲੋ, ਇਸ ਕਲਾਸ ਨੂੰ ਟੌਗਲ ਕਰੋ।” React ਨੇ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਡੀਫੋਲਟ ਵੱਲ ਧੱਕਿਆ:
ਇਹ ਵਿਚਾਰ ਰੋਜ਼ਾਨਾ ਦੇ ਕੰਮ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਕੋਡ ਰਿਵਿਊਜ਼ ਹੁਣ ਪੁੱਛਣ ਲੱਗੇ “ਇਹ state ਕਿੱਥੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ?” ਨਾ ਕਿ “ਤੁਸੀਂ ਕਿਸ selector ਦੀ ਵਰਤੋਂ ਕੀਤੀ?” ਡਿਜ਼ਾਈਨਰ ਅਤੇ ਇੰਜੀਨੀਅਰ ਇੱਕ ਸਾਂਝੇ component ਵਾਕ-ਪਦ ਨੂੰ ਸਮਝ ਸਕਦੇ ਸਨ, ਅਤੇ ਟੀਮਾਂ UI ਬਲੌਕਾਂ ਦੀਆਂ ਲਾਇਬਰੇਰੀਆਂ ਵਧਾ ਸਕਦੀਆਂ ਸਨ ਬਿਨਾਂ ਪੂਰੇ ਪੇਜ਼ ਦੁਬਾਰਾ ਲਿਖਣ ਦੇ।
ਐਨਾ ਹੀ ਨਹੀਂ ਕਿ ਜੇ ਟੀਮ ਬਾਅਦ ਵਿੱਚ ਹੋਰ ਫਰੇਮਵਰਕ 'ਤੇ ਚਲੀ ਵੀ ਜਾਂਦੀ ਹੈ, React-ਦਿੱਤੇ ਗਏ ਆਦਤਾਂ ਬਹੁਤ ਦਿਨ ਤੱਕ ਰਹਿੰਦੇ ਹਨ: ਕੰਪੋਨੈਂਟ-ਅਧਾਰਿਤ ਆਰਕੀਟੈਕਚਰ, declarative rendering, predictable data flow, ਅਤੇ design system ਦੇ ਮੁੜ-ਉਪਯੋਗ ਕੰਪੋਨੈਂਟਾਂ ਦੀ ਪਸੰਦ। React ਨੇ ਇਹ ਪੈਟਰਨ ਆਮ ਕਰ ਦਿੱਤੇ—ਅਤੇ ਇਸ ਨੇ ਵਿਆਪਕ ਫਰੰਟਐਂਡ ਪਰਿਵੇਸ਼ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ।
React ਤੋਂ ਪਹਿਲਾਂ, ਬਹੁਤ ਟੀਮਾਂ ਇੰਟਰਫੇਸ ਨੂੰ ਪੇਜ਼ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਾਉਂਦੀਆਂ ਸਨ, ਨਾ ਕਿ ਮੁੜ-ਉਪਯੋਗ UI ਯੂਨਿਟਾਂ ਦੇ। ਆਮ ਸੈਟਅੱਪ ਸਰਵਰ-ਰੈਂਡਰਡ ਟੈਂਪਲੇਟ (PHP, Rails, Django, JSP ਆਦਿ) ਹੋ ਸਕਦਾ ਸੀ ਜੋ HTML ਤਿਆਰ ਕਰਦਾ ਸੀ, ਅਤੇ ਉੱਪਰ jQuery ਤੜਕਾ ਹੁੰਦਾ ਸੀ ਇੰਟਰਐਕਟਿਵਿਟੀ ਲਈ।
ਤੁਸੀਂ ਇੱਕ ਪੇਜ਼ ਰੈਂਡਰ ਕਰਦੇ, ਫਿਰ ਉਸਨੂੰ ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ “ਸਕ੍ਰਿਯੇਟ” ਕਰਦੇ: datepickers, modal plugins, form validators, carousels—ਹਰੇਕ ਦੀ ਆਪਣੀ markup ਉਮੀਦਾਂ ਅਤੇ event hooks ਹੁੰਦੀਆਂ।
ਕੋਡ ਅਕਸਰ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦਾ: DOM ਨੋਡ ਲੱਭੋ, handler ਜੋੜੋ, DOM ਨੂੰ mutate ਕਰੋ, ਅਤੇ ਆਸ ਕਰੋ ਕਿ ਹੋਰ ਕੁਝ ਤੋੜੇ ਨਾ। ਜਿਵੇਂ ਜਿਵੇਂ UI ਵਧਦਾ ਗਿਆ, “source of truth” ਚੁੱਪਚਾਪ DOM ਖੁਦ ਬਣ ਗਿਆ।
UI ਵਿਹਾਰ ਕਈ ਵਾਰ ਇੱਕ ਥਾਂ ਨਹੀਂ ਰਹਿੰਦਾ ਸੀ। ਇਹ ਵੰਡਿਆ ਹੋਇਆ ਸੀ:
ਇੱਕ single widget—ਜਿਵੇਂ checkout summary—ਦੀ ਤਿਆਰੀ ਹਿਸੇ-ਹਿਸੇ ਸਰਵਰ ਤੇ ਹੁੰਦੀ, AJAX ਨਾਲ ਅੱਪਡੇਟ ਹੁੰਦੀ, ਅਤੇ plugin ਨਾਲ ਨਿਯੰਤਰਿਤ ਹੁੰਦੀ।
ਇਹ ਢੰਗ ਛੋਟੇ enhancements ਲਈ ਕੰਮ ਕਰਦਾ ਸੀ, ਪਰ ਇਹ ਮੁੜ-ਮੁੜ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ:
ਲਾਇਬਰੇਰੀਆਂ ਜਿਵੇਂ Backbone, AngularJS, ਅਤੇ Ember models, views, ਅਤੇ routing ਨਾਲ ਢਾਂਚਾ ਲਿਆਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ—ਅਕਸਰ ਇਹ ਵੱਡੀ ਸੁਧਾਰ ਸੀ। ਪਰ ਬਹੁਤ ਟੀਮਾਂ ਹਜੇ ਵੀ ਪੈਟਰਨ ਮਿਲਾਉਂਦੀਆਂ ਰਹੀਆਂ, ਜਿਸ ਨਾਲ UI ਨੂੰ ਦੁਹਰਾਉਣਯੋਗ ਯੂਨਿਟਾਂ ਵਜੋਂ ਬਿਲਡ ਕਰਨ ਲਈ ਇੱਕ ਸਾਫ਼ ਤੇ ਸਿੰਪਲ ਤਰੀਕੇ ਦੀ ਲੋੜ ਰਹੀ।
React ਦਾ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਬਦਲਾਅ ਆਖਣ ਵਿੱਚ ਸਿੱਧਾ ਅਤੇ ਅਮਲ ਵਿੱਚ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਸ਼ਕਤੀਸ਼ালী ਹੈ: UI state ਦਾ ਫੰਕਸ਼ਨ ਹੈ। DOM ਨੂੰ “source of truth” ਮੰਨਣ ਅਤੇ ਇਸਨੂੰ ਮੈਨੁਅਲੀ ਤੌਰ 'ਤੇ ਸਿੰਕ ਰੱਖਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਆਪਣਾ ਡੇਟਾ ਸਰੋਤ-ਏ-ਸੱਚ ਮੰਨਦੇ ਹੋ ਅਤੇ UI ਨੂੰ ਨਤੀਜੇ ਵਜੋਂ ਛੱਡ ਦਿੰਦੇ ਹੋ।
State ਸਿਰਫ ਉਹ ਮੌਜੂਦਾ ਡੇਟਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਹਾਡੀ ਸਕ੍ਰੀਨ ਨਿਰਭਰ ਕਰਦੀ ਹੈ: ਕੀ ਮੈਨੂ ਖੁੱਲ੍ਹਾ ਹੈ, ਫਾਰਮ ਵਿੱਚ ਕੀ ਟਾਈਪ ਕੀਤਾ ਗਿਆ ਹੈ, ਕਿਸ ਆਈਟਮ ਦੀ ਸੂਚੀ ਹੈ, ਕਿਹੜਾ filter ਚੁਣਿਆ ਗਿਆ ਹੈ।
ਜਦੋਂ state ਬਦਲਦੀ ਹੈ, ਤੁਸੀਂ ਪੇਜ਼ 'ਚ ਕਈ DOM ਨੋਡ ਖੋਜ ਕੇ ਅਪਡੇਟ ਨਹੀਂ ਕਰਦੇ। ਤੁਸੀਂ state ਅਪਡੇਟ ਕਰਦੇ ਹੋ, ਅਤੇ UI ਉਸ ਦੇ ਅਨੁਕੂਲ ਰੈਂਡਰ ਹੋ ਜਾਂਦੀ ਹੈ।
ਪारੰਪਰਿਕ DOM-ਪਹਿਲਾਂ ਕੋਡ ਅਕਸਰ ਵਿਖਰਿਆ ਹੋਇਆ update logic ਪੈਦਾ ਕਰਦਾ ਸੀ:
React ਦੇ ਮਾਡਲ ਨਾਲ, ਇਹ “ਅਪਡੇਟ” ਤੁਹਾਡੇ render ਨਤੀਜੇ ਵਿੱਚ ਸ਼ਰਤਾਂ ਬਣ ਜਾਂਦੀਆਂ ਹਨ। ਸਕ੍ਰੀਨ ਉਸ state ਲਈ ਕੀ ਦਿੱਖਣਾ ਚਾਹੀਦਾ ਹੈ ਇਸਦੀ ਪੜ੍ਹਨਯੋਗ ਵਰਣਨਾ ਬਣ ਜਾਂਦੀ ਹੈ।
function ShoppingList() {
const [items, setItems] = useState([]);
const [text, setText] = useState("");
const add = () => setItems([...items, text.trim()]).then(() => setText(""));
return (
<section>
<form onSubmit={(e) => { e.preventDefault(); add(); }}>
<input value={text} onChange={(e) => setText(e.target.value)} />
<button disabled={!text.trim()}>Add</button>
</form>
{items.length === 0 ? <p>No items yet.</p> : (
<ul>{items.map((x, i) => <li key={i}>{x}</li>)}</ul>
)}
</section>
);
}
ਧਿਆਨ ਦਿਓ ਕਿ empty message, button disabled state, ਅਤੇ list ਸਮੱਗਰੀ ਸਾਰੇ items ਅਤੇ text ਤੋਂ ਨਿੱਕਲਦੇ ਹਨ। ਇਹ ਆਰਕੀਟੈਕਚਰਕ ਫਾਇਦਾ ਹੈ: ਡੇਟਾ ਦੀ ਸ਼ਕਲ ਅਤੇ UI ਦੀ ਬਣਤਰ ਇਕ-ਦੂਜੇ ਨਾਲ ਮਿਲਦੇ ਹਨ, ਜਿਸ ਨਾਲ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਸੋਚਣਾ, ਟੈਸਟ ਕਰਨਾ ਅਤੇ ਵਿਕਸਿਤ ਕਰਨਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
React ਨੇ “component” ਨੂੰ ਡੀਫੋਲਟ UI ਯੂਨਿਟ ਬਣਾਇਆ: ਇੱਕ ਛੋਟੀ, ਮੁੜ-ਉਪਯੋਗ ਟੁਕੜੀ ਜੋ markup, ਬਿਹੇਵਿਯਰ, ਅਤੇ styling hooks ਨੂੰ ਇੱਕ ਸਾਫ਼ ਇੰਟਰਫੇਸ ਦੇ ਪਿੱਛੇ ਬੰਨ੍ਹਦੀ ਹੈ।
HTML ਟੈਮਪਲੇਟ, ਇਵੈਂਟ ਲਿਸਨਰ, ਅਤੇ CSS selectors ਨੂੰ ਅਲੱਗ-ਅਲੱਗ ਫਾਈਲਾਂ ਵਿੱਚ ਵਿਖਰਾਉਣ ਦੀ ਬਜਾਏ, ਇੱਕ component ਚੱਲਦੇ-ਫਿਰਦੇ ਹਿੱਸਿਆਂ ਨੂੰ ਨੇੜੇ ਰੱਖਦਾ ਹੈ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਹਰ ਚੀਜ਼ ਇੱਕ ਹੀ ਫਾਈਲ ਵਿੱਚ ਰਹੇ—ਪਰ ਕੋਡ ਇਸ ਗੱਲ ਦੇ ਆਧਾਰ 'ਤੇ ਸੰਗਠਿਤ ਹੁੰਦਾ ਹੈ ਕਿ ਉਪਭੋਗਤਾ ਕੀ ਦੇਖਦਾ ਅਤੇ ਕਰਦਾ ਹੈ, ਨਾ ਕਿ DOM API।
ਇੱਕ ਪ੍ਰਯੋਗਕ component ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ:
ਮੁੱਖ ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ “ਇਸ div ਨੂੰ ਅਪਡੇਟ ਕਰੋ” ਦੀ ਸੋਚ ਛੱਡ ਦਿੰਦੇ ਹੋ ਅਤੇ “ਇਸ Button ਨੂੰ ਉਸ ਦੇ disabled state ਵਿੱਚ render ਕਰੋ” ਦੀ ਸੋਚ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ।
ਜਦੋਂ ਇੱਕ component ਥੋੜ੍ਹੇ props (inputs) ਅਤੇ events/callbacks (outputs) ਨੂੰ ਖੋਲ੍ਹਦਾ ਹੈ, ਤਾਂ ਇਸ ਦੇ ਅੰਦਰਲੇ ਹਿੱਸਿਆਂ ਨੂੰ ਬਦਲਣਾ ਬਿਨਾਂ ਬਾਕੀ ਐਪ ਨੂੰ ਤੋੜੇ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਟੀਮਾਂ ਵਿਸ਼ੇਸ਼ components ਜਾਂ ਫੋਲਡਰ (ਉਦਾਹਰਨ ਲਈ, “checkout UI”) ਦੀ ਮਾਲਕੀ ਲੈਂਦੀਆਂ ਹਨ ਅਤੇ ਨਿਰਭਿੱਕ ਹੋ ਕੇ ਸੁਧਾਰ ਕਰ ਸਕਦੀਆਂ ਹਨ।
Encapsulation ਨਾਲ accidental coupling ਘਟਦਾ ਹੈ: ਘੱਟ global selectors, ਘੱਟ cross-file side effects, ਘੱਟ “ਇਹ click handler ਕਿਉਂ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਗਿਆ?” ਵਾਲੀਆਂ ਚੌਕਾਂ।
ਜਿਵੇਂ ਹੀ components ਮੁੱਖ ਬਿਲਡਿੰਗ ਬਲਾਕ ਬਣੇ, ਕੋਡ ਪ੍ਰੋਡਕਟ ਦੇ ਨਕਸ਼ੇ ਨੂੰ ਦਰਸਾਉਣ ਲੱਗਾ:
ਇਹ ਮੇਲ UI ਗੱਲਬਾਤ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ: ਡਿਜ਼ਾਈਨਰ, PM, ਅਤੇ ਇੰਜੀਨੀਅਰ ਇਕੋ “ਚੀਜ਼ਾਂ” ਬਾਰੇ ਗੱਲ ਕਰ ਸਕਦੇ ਹਨ।
Component ਸੋਚ ਨੇ ਬਹੁਤ ਸਾਰੇ ਕੋਡਬੇਸ ਨੂੰ feature- ਜਾਂ domain-ਅਧਾਰਿਤ ਰੰਗ-ਰੂਪ ਦੀ ਓਰ ਧੱਕਿਆ (ਉਦਾਹਰਨ: /checkout/components/CheckoutForm) ਅਤੇ ਸਾਂਝੀ UI ਲਾਇਬਰੇਰੀਆਂ (/ui/Button) ਵੱਲ। ਜਦ ਫੀਚਰ ਵਧਦੇ ਹਨ, ਇਹ ਢਾਂਚਾ ਪੇਜ-ਕੇਵਲ ਫੋਲਡਰਾਂ ਨਾਲੋਂ ਬਿਹਤਰ ਸਕੇਲ ਕਰਦਾ ਹੈ ਅਤੇ design systems ਲਈ ਮੰਚ ਤਿਆਰ ਕਰਦਾ ਹੈ।
React ਦੀ rendering estilo ਨੂੰ ਅਕਸਰ declarative ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਦਾ ਸਧਾਰਨ ਮਤਲਬ ਹੈ: ਤੁਸੀਂ ਦੱਸਦੇ ਹੋ ਕਿ ਕਿਸ ਹਾਲਤ ਵਿੱਚ UI ਕਿਵੇਂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ React ਬਰਾਉਜ਼ਰ ਨੂੰ ਇਸਨੂੰ ਮਿਲਾਉਣ ਲਈ ਜਿੱਦੀਆਂ ਲੋੜੀਂਦੀਆਂ ਚੀਜ਼ਾਂ ਹੋਣਗੀਆਂ ਉਹ ਕਰਦਾ ਹੈ।
ਪੁਰਾਣੀਆਂ DOM-ਪਹਿਲਾਂ ਪਹੁੰਚਾਂ ਵਿੱਚ ਤੁਸੀਂ ਅਕਸਰ ਕਦਮ-ਬਦ-ਕਦਮ ਹਦਾਇਤਾਂ ਲਿਖਦੇ:
Declarative rendering ਵਿੱਚ, ਤੁਸੀਂ ਨਤੀਜੇ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹੋ:
ਜੇ ਯੂਜ਼ਰ ਲੌਗਿਨ ਹੈ, ਤਾਂ ਉਸਦਾ ਨਾਮ ਦਿਖਾਓ; ਨਹੀਂ ਤਾਂ “Sign in” ਬਟਨ ਦਿਖਾਓ।
ਇਹ ਬਦਲਾਅ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ “UI bookkeeping” ਦੀ ਮਾਤਰਾ ਘਟਾਂਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਕਰਨੀਆਂ ਪੈਂਦੀਆਂ ਸਨ। ਤੁਸੀਂ ਲਗਾਤਾਰ ਇਹ ਨਹੀਂ ਟ੍ਰੈਕ ਕਰ ਰਹੇ ਕਿ ਕਿਹੜੇ ਐਲੀਮੈਂਟ ਮੌਜੂਦ ਹਨ ਅਤੇ ਕੀ ਅਪਡੇਟ ਹੋਣਾ ਚਾਹੀਦਾ—ਤੁਸੀਂ ਅਪਣੇ ਐਪ ਦੇ states 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਦੇ ਹੋ।
JSX ਇਕ ਸੁਵਿਧਾਜਨਕ ਤਰੀਕਾ ਹੈ UI ਸਰਚਨਾ ਨੂੰ ਉਸ ਲਾਜਿਕ ਦੇ ਨੇੜੇ ਲਿਖਣ ਦਾ ਜੋ ਇਸਨੂੰ ਕੰਟਰੋਲ ਕਰਦੀ ਹੈ। template ਫਾਈਲਾਂ ਅਤੇ logic ਫਾਈਲਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਰੱਖਣ ਦੇ ਬਦਲੇ, ਤੁਸੀਂ ਸੰਬੰਧਤ ਹਿੱਸੇ ਇਕੱਠੇ ਰੱਖ ਸਕਦੇ ਹੋ: markup-ਜੈਸੀ ਬਣਤਰ, ਸ਼ਰਤਾਂ, ਛੋਟੇ formatting ਫੈਸਲੇ, ਅਤੇ event handlers।
ਇਹ co-location ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹੈ ਕਿ React ਦਾ component ਮਾਡਲ عملي ਮਹਿਸੂਸ ਹੋਇਆ। ਇੱਕ component ਸਿਰਫ HTML ਦਾ ਟੁਕੜਾ ਜਾਂ JavaScript ਦਾ ਬੰਡਲ ਨਹੀਂ—ਇਹ UI ਵਿਹਾਰ ਦੀ ਇੱਕ ਯੂਨਿਟ ਹੈ।
ਲੋਕਾਂ ਨੂੰ ਖ਼ਿਆਲ ਆਉਂਦਾ ਹੈ ਕਿ JSX HTML ਅਤੇ JavaScript ਨੂੰ ਮਿਲਾ ਰਿਹਾ ਹੈ, ਜੋ ਪਿੱਛੇ ਵਧਣ ਵਰਗਾ ਲੱਗਦਾ ਹੈ। ਪਰ JSX ਅਸਲ ਵਿੱਚ HTML ਨਹੀਂ ਹੈ—ਇਹ syntax ਹੈ ਜੋ JavaScript ਕਾਲਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ React ਤਕਨੀਕਾਂ ਨੂੰ ਮਿਲਾ ਰਿਹਾ ਨਹੀਂ, ਬਲਕਿ ਉਹ ਚੀਜ਼ਾਂ ਜੋ ਇਕੱਠੇ ਬਦਲਦੀਆਂ ਹਨ ਉਹਨਾਂ ਨੂੰ ਇਕੱਠੇ ਰੱਖ ਰਿਹਾ ਹੈ।
ਲਾਜ਼ਮੀ ਨਹੀਂ ਕਿ JSX ਹੀ declarative rendering ਦਾ ਇਕੱਲਾ ਰਸਤਾ ਹੈ—ਤੁਸੀਂ React ਬਿਨਾਂ JSX ਦੇ ਵੀ ਲਿੱਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਹੋਰ ਫਰੇਮਵਰਕ ਵੀ declarative rendering ਵਰਤਦੇ ਹਨ। ਮੁੱਖ ਪ੍ਰਭਾਵ ਇਹ ਮਾਨਸਿਕਤਾ ਰਹਿੰਦੀ ਹੈ: UI ਨੂੰ state ਦਾ ਫੰਕਸ਼ਨ ਮੰਨੋ ਅਤੇ framework ਨੂੰ ਸਕ੍ਰੀਨ ਨੂੰ ਸਿੰਕ ਰੱਖਣ ਦੀ ਮਿਹਨਤ ਸੌਂਪੋ।
React ਤੋਂ ਪਹਿਲਾਂ, ਆਮ ਬੱਗ ਇਸ ਕਾਰਨ ਹੁੰਦੇ ਸਨ: ਡੇਟਾ ਬਦਲ ਗਿਆ ਪਰ UI ਨਹੀਂ। ਡਿਵੈਲਪਰ ਨਵਾਂ ਡੇਟਾ ਫੈਚ ਕਰਦਾ, ਫਿਰ ਹੱਥੋਂ-ਹੱਥ ਠੀਕ DOM ਨੋਡ ਲੱਭ ਕੇ ਟੈਕਸਟ ਅਪਡੇਟ ਕਰਦੇ, ਕਲਾਸ ਟੌਗਲ ਕਰਦੇ, ਐਲੀਮੈਂਟ ਜੋੜਦੇ/ਹਟਾਂਦੇ, ਅਤੇ ਇਹ ਸਭ ਕਈ ਵਾਰ ਉਦਾਹਰਣਾਂ ਤੇ ਹੀ ਭਾਰੀ ਹੋ ਜਾਂਦਾ। ਸਮੇਂ ਦੇ ਨਾਲ, “update logic” ਅਕਸਰ UI ਨਾਲੋਂ ਵੱਧ ਜਟਿਲ ਹੋ ਗਿਆ।
React ਦਾ ਵੱਡਾ workflow ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ browser ਨੂੰ ਇਹ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਪੇਜ਼ ਕਿਵੇਂ ਬਦਲਣਾ ਹੈ। ਤੁਸੀਂ ਉਸ state ਲਈ UI ਦੀ ਵਰਣਨਾ ਕਰਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ React ਅਸਲੀ DOM ਨੂੰ ਮਿਲਾਉਣ ਲਈ ਕਿਹੜੇ-ਕਿਹੜੇ ਤਬਦੀਲੀਆਂ ਕਰਨੀਆਂ ਹਨ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ।
Reconciliation React ਦੀ ਉਹ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਤੁਲਨਾ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਪਿਛਲੇ ਵਲੋਂ ਕੀ ਰੈਂਡਰ ਕੀਤਾ ਸੀ ਅਤੇ ਹੁਣ ਕੀ ਰੈਂਡਰ ਕਰ ਰਹੇ ਹੋ, ਫਿਰ browser DOM 'ਤੇ ਘੱਟੋ-ਘੱਟ ਬਦਲਾਵ ਲਗਾਉਂਦਾ ਹੈ।
ਮੁੱਖ ਗੱਲ ਇਹ ਨਹੀਂ ਕਿ React Virtual DOM ਨੂੰ ਇੱਕ ਜਾਦੂਈ ਪਰਫਾਰਮੈਂਸ ਚਾਲਕੇ ਵਰਤਦਾ ਹੈ। ਮੈਦਾ ਹਨ ਕਿ React ਤੁਹਾਨੂੰ ਇਕ ਪਹੁੰਚ ਦਿੰਦਾ ਹੈ ਜੋ ਪੇਸ਼ਗੋਈਯੋਗ ਹੈ:
ਇਹ ਪੇਸ਼ਗੋਈ ਵਿਕਾਸਕਾਰਾਂ ਦੇ ਵਰਕਫਲੋ ਨੂੰ ਸੁਧਾਰਦੀ ਹੈ: ਘੱਟ ਮੈਨੁਅਲ DOM ਅਪਡੇਟ, ਘੱਟ ਅਸੰਗਤ ਸਟੇਟ, ਅਤੇ ਐਪ-ਭਰ ਇੱਕੋ ਨਿਯਮਾਂ ਅਨੁਸਾਰ UI ਅਪਡੇਟ।
ਲਿਸਟਾਂ ਰੈਂਡਰ ਕਰਦੇ ਸਮੇਂ, React ਨੂੰ reconciliation ਦੌਰਾਨ “ਪੁਰਾਣੇ ਆਈਟਮਾਂ” ਨੂੰ “ਨਵੇਂ ਆਈਟਮਾਂ” ਨਾਲ ਮਿਲਾਉਣ ਲਈ ਇੱਕ stable ਤਰੀਕਾ ਚਾਹੀਦੀ ਹੈ। ਏਹੀ key ਲਈ ਹੈ।
{todos.map(todo => (
<TodoItem key={todo.id} todo={todo} />
))}
ਸਟੇਬਲ ਅਤੇ unique keys ਵਰਤੋ (ਜਿਵੇਂ ID). ਜਦ items reorder, insert, ਜਾਂ delete ਹੋ ਸਕਦੇ ਹਨ ਤਾਂ array indexes ਤੋਂ ਪਰਹੇਜ਼ ਕਰੋ—ਨਹੀਂ ਤਾਂ React ਗਲਤ component instance reuse ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ hairaan ਕਰਨ ਵਾਲਾ UI ਵਿਹਾਰ ਹੋ ਸਕਦਾ ਹੈ (ਜਿਵੇਂ inputs ਗਲਤ value ਰੱਖ ਲੈਂਦੇ)।
React ਦਾ ਇੱਕ ਵੱਡਾ ਆਰਕੀਟੈਕਚਰਕ ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਡੇਟਾ ਇੱਕ ਦਿਸ਼ਾ ਵਿੱਚ ਚਲਦੀ ਹੈ: ਮਾਪੇ ਤੋਂ ਬੱਚਿਆਂ ਵੱਲ। ਕਿਸੇ ਵੀ ਹਿੱਸੇ ਨੂੰ ਹੋਰ ਹਿੱਸਿਆਂ ਵਿੱਚ “ਘੁੱਸ ਕੇ” shared state ਨੂੰ ਬਦਲਣ ਦੀ ਆਗਿਆ ਦੇਣ ਦੀ ਬਜਾਏ, React ਤੁਹਾਨੂੰ ਅਪਡੇਟ ਨੂੰ explicit events ਵਜੋਂ ਉੱਪਰ ਭੇਜਣ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਨਤੀਜਾ ਡਾਟਾ ਨੀਚੇ ਵਲ ਆਉਂਦਾ ਹੈ।
function Parent() {
const [count, setCount] = React.useState(0);
return (
<Counter
value={count}
onIncrement={() => setCount(c => c + 1)}
/>
);
}
function Counter({ value, onIncrement }) {
return (
<button onClick={onIncrement}>
Clicks: {value}
</button>
);
}
ਧਿਆਨ ਦਿਓ ਕਿ ਕੀ ਨਹੀਂ ਹੁੰਦਾ: Counter count ਨੂੰ ਸੀਧਾ ਨਹੀਂ ਬਦਲਦਾ। ਇਹ value (ਡੇਟਾ) ਅਤੇ onIncrement (ਬਦਲਾਅ ਦੀ ਮੰਗ) ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਇਹ ਵੱਖਰਾ ਪਾਰਦਰਸ਼ਤਾ ਮਾਨਸਿਕ ਮਾਡਲ ਦੀ ਕੋਰ ਹੈ।
ਇਹ ਪੈਟਰਨ ਸਰਹੱਦਾਂ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਂਦਾ ਹੈ: “ਇਹ ਡੇਟਾ ਕਿਸ ਦਾ ਹੈ?” ਦਾ ਜਵਾਬ ਆਮ ਤੌਰ 'ਤੇ “ਨਜ਼ਦੀਕੀ ਸਾਂਝਾ ਮਾਪੇ” ਹੁੰਦਾ ਹੈ। ਜਦ ਕੁਝ ਅਣ ਉਮੀਦ ਤੌਰ 'ਤੇ ਬਦਲਦਾ ਹੈ, ਤੁਸੀਂ ਉਸ ਜਗ੍ਹਾ ਤੱਕ ਟ੍ਰੇਸ ਕਰਦੇ ਹੋ ਜਿੱਥੇ state ਮੌਜੂਦ ਹੈ—ਨਹੀਂ ਤਾਂਆਂ ਛੁਪੇ mutations ਵਾਲੇ ਜਾਲ ਰਾਹੀਂ।
ਇਹ ਫਰਕ ਟੀਮਾਂ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿ ਕਹਿਰ_logic ਕਿੱਥੇ ਹੋਵੇ ਅਤੇ ਅਕਸਮੀ coupling ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਜਿਹੜੇ component props 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ, ਉਹ ਮੁੜ-ਉਪਯੋਗ ਕਰਨ ਯੋਗ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ global variables ਜਾਂ DOM queries 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੁੰਦੇ। ਉਹਨਾਂ ਨੂੰ ਟੈਸਟ ਕਰਨਾ ਵੀ ਸਾਦਾ ਹੈ: ਤੁਸੀ ਉਹਨਾਂ ਨੂੰ ख़ਾਸ props ਦੇ ਕੇ render ਕਰੋ ਅਤੇ ਨਤੀਜੇ ਨੂੰ assert ਕਰੋ, ਜਦਕਿ stateful ਵਿਵਹਾਰ ਨੂੰ ਓਥੇ ਜਾਂਚਿਆ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ state manage ਹੁੰਦੀ ਹੈ।
React ਨੇ ਟੀਮਾਂ ਨੂੰ UI ਲਈ class hierarchies ਦੀ ਭੀੜ ਤੋਂ ਓੜ੍ਹਕੇ ਛੋਟੇ, ਕੇਂਦਰਿਤ ਟੁਕੜਿਆਂ ਨਾਲ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਜੋੜਨ ਵੱਲ ਧੱਕਿਆ। ਬਦਲੇ ਵਿੱਚ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ gedrag ਅਤੇ ਦ੍ਰਿਸ਼ਟੀ ਨੂੰ ਛੋਟੇ components ਨੂੰ ਮਿਲਾ ਕੇ ਬਣਾਉਂਦੇ ਹੋ।
ਆਮ ਪੈਟਰਨ layout components ਬਣਾਉਣਾ ਹੈ ਜੋ ਡੇਟਾ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਜਾਣਦੇ:
PageShell header/sidebar/footer ਲਈStack / Grid spacing ਅਤੇ alignment ਲਈCard consistent framing ਲਈਇਹ components children ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ ਤਾਂ ਕਿ ਪੇਜ਼ ਫ਼ੈਸਲਾ ਕਰੇ ਕਿ ਅੰਦਰ ਕੀ ਰੱਖਣਾ ਹੈ, ਨ ਕਿ layout।
ਤੁਸੀਂ ਹਲਕੇ wrappers ਵੀ ਵੇਖੋਂਗੇ ਜਿਵੇਂ RequireAuth ਜਾਂ ErrorBoundary ਜੋ ਜੋੜੇ ਗਏ ਕੰਪੋਨੈਂਟ 'ਤੇ ਚਿੰਤਾ ਜੋੜਦੇ ਹਨ ਬਿਨਾਂ ਉਸਦੇ ਅੰਦਰੂਨੀ ਹਿੱਸੇ ਬਦਲੇ।
ਜਦੋਂ “ਸਿਰਫ children” ਤੋਂ ਜ਼ਿਆਦਾ ਕਾਬੂ ਚਾਹੀਦਾ ਹੈ, ਟੀਮਾਂ ਅਕਸਰ props ਰਾਹੀਂ slot-like 접근 ਵਰਤਦੀਆਂ ਹਨ:
Modal ਨਾਲ title, footer, ਅਤੇ childrenTable ਨਾਲ renderRow ਜਾਂ emptyStateਇਸ ਨਾਲ components ਲਚਕੀਲੇ ਰਹਿੰਦੇ ਹਨ ਬਿਨਾਂ API surface ਨੂੰ ਵਧਣ ਦੇ।
ਗਹਿਰੀ inheritance trees ਆਮ ਤੌਰ 'ਤੇ ਚੰਗੇ ਇरਾਦਿਆਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ, ਪਰ ਉਹ ਕੰਟਰੋਲ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਂਦੀਆਂ:
Hooks ਨੇ composition ਨੂੰ ਹੋਰ ਪ੍ਰਯੋਗਕ ਬਣਾਇਆ। ਇੱਕ custom hook ਜਿਵੇਂ useDebouncedValue ਜਾਂ usePermissions ਕਈ feature components ਨੂੰ logic share ਕਰਨ ਦਿੰਦੇ ਹਨ ਬਗੈਰ UI share ਕੀਤੇ। ਇਸਨੂੰ shared UI primitives (buttons, inputs, typography) ਅਤੇ feature components (CheckoutSummary, InviteUserForm) ਦੇ ਨਾਲ ਜੋੜੋ, ਅਤੇ ਤੁਹਾਨੂੰ ਏਸੇ ਤਰ੍ਹਾਂ ਦਾ reuse ਮਿਲਦਾ ਹੈ ਜੋ ਐਪ ਵਧਣ 'ਤੇ ਵੀ ਸਮਝਣਯੋਗ ਰਹਿੰਦਾ ਹੈ।
React ਨੇ local component state ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਨੂੰ ਨੇਚੁਰਲ ਬਣਾਇਆ: ਇੱਕ ਫਾਰਮ ਫੀਲਡ ਦੀ value, ਇੱਕ dropdown ਖੁੱਲ੍ਹਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇੱਕ loading spinner। ਇਹ ਚੰਗਾ ਕੰਮ ਕਰਦਾ—ਪਰ ਜਦ ਐਪ ਵੱਡਾ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਈ ਹਿੱਸਿਆਂ ਨੂੰ sync ਵਿੱਚ ਰਹਿਣਾ ਪੈਂਦਾ ਹੈ ਤਾਂ ਸਮੱਸਿਆ ਆਉਂਦੀ ਹੈ।
ਜਿਵੇਂ ਜਿਵੇਂ ਫੀਚਰ ਫੈਲਦੇ ਹਨ, state ਨੂੰ ਅਕਸਰ ਉਹਨਾਂ ਕੰਪੋਨੈਂਟਾਂ ਦੁਆਰਾ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਜਾਂ ਅਪਡੇਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜੋ parent-child ਰਿਸ਼ਤੇ ਵਿੱਚ ਨਹੀਂ ਹੁੰਦੇ। “ਜստ props ਪਾਸ ਕਰੋ” prop drilling ਬਣ ਕੇ ਲੰਮੇ ਚੇਨ ਬਣ ਜਾਂਦੀ, ਜਿਸ ਨਾਲ refactor ਕਰਨਾ ਖਤਰਨਾਕ ਹੋ ਜਾਂਦਾ, boilerplate ਵਧਦਾ, ਅਤੇ ਦੋ ਥਾਵਾਂ 'ਚ ਇਕੋ state ਹੋਣ ਦੇ ਭਾਵ ਨਾਲ confusions ਪੈਦਾ ਹੁੰਦੇ।
1) Lifting state up
State ਨੂੰ ਨੇੜਲੇ common parent 'ਤੇ ਲੈ ਜਾਉ ਅਤੇ ਉਸਨੂੰ props ਰਾਹੀਂ ਨੀਚੇ ਵੱਗਾਓ। ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਸਧਾਰਣ ਵਿਕਲਪ ਹੈ ਅਤੇ dependencies ਨੂੰ explicit ਰੱਖਦਾ ਹੈ, ਪਰ ਜੇੀ ਜ਼ਿਆਦਾ ਵਰਤੋਂ ਹੋਵੇ ਤਾਂ “god components” ਬਣ ਸਕਦੇ ਹਨ।
2) Context for shared, app-wide concerns
React Context ਉਹ ਸਮੇਂ ਮਦਦ ਕਰਦਾ ਹੈ ਜਦ ਕਈ components ਨੂੰ ਇਕੋ value ਚਾਹੀਦੀ ਹੈ (theme, locale, current user)। ਇਹ prop drilling ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ, ਪਰ ਜੇ ਤੁਸੀਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਬਦਲਣ ਵਾਲਾ ਡੇਟਾ context ਵਿੱਚ ਰੱਖੋਗੇ ਤਾਂ updates ਅਤੇ performance ਨੂੰ ਸਮਝਣਾ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ।
3) External stores
ਜਦ React ਐਪ ਵੱਡੇ ਹੋਏ, ecosystem ਨੇ Redux ਵਰਗੀਆਂ ਲਾਇਬਰੇਰੀਆਂ ਨਾਲ ਜਵਾਬ ਦਿੱਤਾ। ਇਹ state updates ਨੂੰ ਕੇਂਦਰੀਕ੍ਰਿਤ ਕਰਦੇ ਹਨ, ਅਕਸਰ actions ਅਤੇ selectors ਦੇ ਨਿਯਮ ਕਿਸੇ ਟੀਮ ਨੂੰ predictable updates ਦੇ ਸਕਦੇ ਹਨ।
ਮੂਲ ਤੌਰ 'ਤੇ local state ਚੁਣੋ, ਜਦ siblings ਨੂੰ coordinate ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ state ਨੂੰ ਉੱਪਰ ਲਿਜਾਓ, cross-cutting concerns ਲਈ context ਵਰਤੋ, ਅਤੇ ਜਦ ਕਈ ਦੂਰੇ components ਇੱਕੋ ਡੇਟਾ 'ਤੇ ਨਿਰਭਰ ਕਰਨ ਤਾਂ external store ਖ਼ਿਆਲ ਕਰੋ। “ਸਹੀ” ਚੋਣ trend ਤੋਂ ਘੱਟ ਅਤੇ ਐਪ ਦੀ complexity, ਟੀਮ ਆਕਾਰ, ਅਤੇ ਬਦਲਾਅ ਦੀ ਤੀਵ੍ਰਤਾ 'ਤੇ ਵੱਧ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।
React ਸਿਰਫ਼ UI ਲਿਖਣ ਦਾ ਤਰੀਕਾ ਨਹੀਂ ਦਿਤਾ—ਇਸ ਨੇ ਟੀਮਾਂ ਨੂੰ ਇਕ component-driven workflow ਵੱਲ ਧੱਕਿਆ ਜਿੱਥੇ ਕੋਡ, styling, ਅਤੇ ਵਿਹਾਰ ਛੋਟੇ, ਟੈਸਟੇਬਲ ਯੂਨਿਟਾਂ ਵਜੋਂ ਵਿਕਸਿਤ ਹੁੰਦੇ ਹਨ। ਇਹ ਬਦਲਾਅ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਕਿ ਫਰੰਟਐਂਡ ਪ੍ਰੋਜੈਕਟ ਕਿਵੇਂ ਬਣਾਏ, ਵੈਰੀਫਾਈ, ਦਸਤੀavez, ਅਤੇ ਸ਼ਿਪ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।
ਜਦ UI components ਨਾਲ ਬਣਿਆ ਹੋਇਆ ਹੁੰਦਾ ਹੈ, ਤਾਂ “edges ਤੋਂ inward” ਕੰਮ ਕਰਨਾ ਕੁਦਰਤੀ ਬਣ ਜਾਂਦਾ ਹੈ: ਪਹਿਲਾਂ ਇੱਕ button ਬਣਾਓ, ਫਿਰ ਇੱਕ form, ਫਿਰ ਇੱਕ page। ਟੀਮਾਂ components ਨੂੰ products ਵਾਂਗ ਸੋਚਣ ਲੱਗਦੀਆਂ ਹਨ—ਸਾਫ਼ APIs (props), predictable states (loading, empty, error), ਅਤੇ reusable styling rule।
ਇੱਕ ਪ੍ਰਯੋਗਕ ਬਦਲਾਅ: ਡਿਜ਼ਾਈਨਰ ਅਤੇ ਡਿਵੈਲਪਰ ਇੱਕ ਸਾਂਝੇ component inventory 'ਤੇ ਮਿਲਦੇ ਹਨ, ਅਲੱਗ-ਅਲੱਗ ਹਾਲਤਾਂ ਵਿੱਚ ਵਿਹਾਰ ਰਿਵਿਊ ਕਰਦੇ ਹਨ, ਅਤੇ ਆਖ਼ਰੀ ਵੇਲੇ page-ਸਤਰ ਦੇ surprises ਘੱਟ ਹੋ ਜਾਂਦੇ ਹਨ।
React ਦੀ lokpriyਤਾ ਨੇ ਇੱਕ ਆਧੁਨਿਕ ਟੂਲਚੇਨ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ ਜੋ ਬਹੁਤ ਟੀਮਾਂ ਹੁਣ ਮਿਆਰੀ ਮੰਨਦੀਆਂ ਹਨ:
ਯਦਿੱ ਤੁਸੀਂ ਉਹੋ ਹੀ ਟੂਲ ਚੁਣਦੇ ਨਹੀਂ ਵੀ, ਉਮੀਦ ਇਹ ਰਹਿੰਦੀ ਹੈ ਕਿ ਇੱਕ React ਐਪ ਵਿੱਚ guardrails ਹੋਣ ਜੋ UI regressions ਨੂੰ ਜਲਦੀ ਫੜ ਲੈਂਦੇ।
ਇਸ “workflow-first” ਸੋਚ ਦੇ ਨਵੇਂ ਵਾਧੇ ਵਜੋਂ, ਕੁਝ ਟੀਮਾਂ vibe-coding ਪਲੇਟਫਾਰਮਾਂ (ਉਦਾਹਰਨ: Koder.ai) ਵਰਤਦੀਆਂ ਹਨ ਜੋ React frontends (ਅਤੇ ਨਾਲ ਦਾ backend) ਨੂੰ chat-driven planning flow ਤੋਂ scaffold ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ—ਜਦ ਤੁਸੀਂ component structure, state ownership, ਅਤੇ feature boundaries ਨੂੰ ਤੁਰੰਤ ਵੈਰੀਫਾਈ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਇਹ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ।
React ਟੀਮਾਂ ਨੇ component explorer ਦਾ ਵਿਚਾਰ ਵੀ ਲੋਕਪ੍ਰਿਯ ਕੀਤਾ: ਇੱਕ ਅਲੱਗ ਮਾਹੌਲ ਜਿੱਥੇ ਤੁਸੀਂ components ਨੂੰ ਵੱਖ-ਵੱਖ states ਵਿੱਚ ਰੈਂਡਰ ਕਰ ਸਕਦੇ ਹੋ, ਨੋਟ ਜੋੜ ਸਕਦੇ ਹੋ, ਅਤੇ ਵਰਤੋਂ-ਮਾਰਗਦਰਸ਼ਨ ਲਈ ਇੱਕ ਇੱਕੋ ਸਰੋਤ ਰੱਖ ਸਕਦੇ ਹੋ।
ਇਹ “Storybook-style” ਸੋਚ (ਕਿਸੇ ਵਿਸ਼ੇਸ਼ ਉਤਪਾਦ ਦੀ ਲੋੜ ਬਗੈਰ) ਸਹਿਯੋਗ ਬਦਲ ਦਿੰਦੀ: ਤੁਸੀਂ ਇੱਕ component ਦੇ ਵਿਹਾਰ ਨੂੰ ਉਸ ਨੂੰ ਪੇਜ਼ ਨਾਲ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਰਿਵਿਊ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ edge cases ਨੂੰ ਮਨਮੁਤਾਬਕ ਤਰੀਕੇ ਨਾਲ ਵੈਰੀਫਾਈ ਕਰ ਸਕਦੇ ਹੋ।
ਜੇ ਤੁਸੀਂ ਇੱਕ reusable library ਬਣਾ ਰਹੇ ਹੋ, ਤਾਂ ਇਹ design system ਨਜ਼ਰੀਏ ਨਾਲ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜੁੜਦਾ—ਦੇਖੋ /blog/design-systems-basics.
Component-based tooling ਛੋਟੇ pull requests, ਸਪੱਸ਼ਟ visual review, ਅਤੇ ਸੁਰੱਖਿਅਤ refactors ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ। ਸਮੇਂ ਦੇ ਨਾਲ, ਟੀਮਾਂ UI ਬਦਲਾਅ ਤੇਜ਼ੀ ਨਾਲ ਸ਼ਿਪ ਕਰਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਉਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੀਮਿਤ ਟੁਕੜਿਆਂ 'ਤੇ iteration ਕਰ ਰਹੇ ਹੁੰਦੇ ਹਨ ਬਜਾਏ tangled, page-wide DOM ਕੋਡ ਵਿੱਚ ਘੁੰਮਣ ਦੇ।
ਇੱਕ design system ਅਮਲੀ ਰੂਪ ਵਿੱਚ ਦੋ ਚੀਜ਼ਾਂ ਹਨ: reusable UI components ਦੀ ਲਾਇਬਰੇਰੀ (buttons, forms, modals, navigation) ਅਤੇ ਹਦਾਇਤਾਂ ਜੋ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਉਹ ਕਦੋਂ ਅਤੇ ਕਿਵੇਂ ਵਰਤਣੀਆਂ ਹਨ (spacing, typography, tone, accessibility rules, interaction patterns)।
React ਨੇ ਇਹ ਵਿਧੀ ਕੁਦਰਤੀ ਬਣਾਈ ਕਿਉਂਕਿ “component” ਪਹਿਲੋਂ ਹੀ UI ਦਾ ਮੁੱਖ ਯੂਨਿਟ ਹੈ। pages ਵਿੱਚ markup ਨਕਲ ਕਰਨ ਦੀ ਬਜਾਏ, ਟੀਮਾਂ ਇੱਕ \u003cButton /\u003e, \u003cTextField /\u003e, ਜਾਂ \u003cDialog /\u003e ਇਕ ਵਾਰੀ ਪਬਲਿਸ਼ ਕਰ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਹਰ ਜਗ੍ਹਾ ਦੁਬਾਰਾ ਵਰਤ ਸਕਦੀਆਂ ਹਨ—ਫਿਰ ਵੀ props ਰਾਹੀਂ ਨਿਰੀਕ੍ਰਿਤ ਕੁਝ ਕਸਟਮਾਈਜ਼ੇਸ਼ਨ ਦੀ ਆਗਿਆ ਮਿਲਦੀ ਹੈ।
React components self-contained ਹੁੰਦੇ ਹਨ: ਉਹ structure, ਵਿਹਾਰ, ਅਤੇ styling ਨੂੰ ਇੱਕ ਸਥਿਰ ਇੰਟਰਫੇਸ ਦੇ ਪਿੱਛੇ ਬੰਨ੍ਹ ਸਕਦੇ ਹਨ। ਇਹ ਇੱਕ component library ਬਣਾਉਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਜੋ:
ਜੇ ਤੁਸੀਂ ਨਵੇਂ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹੋ, ਇੱਕ ਸਧਾਰਣ ਚੈੱਕਲਿਸਟ ਇਸ ਗੱਲ ਨੂੰ ਰੋਕਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ ਕਿ “ਕੰਪੋਨੈਂਟਾਂ ਦਾ ਇਕ ਢੇਰ” inconsistent ਗਰਮੀ ਵਿੱਚ ਨਹੀਂ ਬਦਲ ਜਾਏ: /blog/component-library-checklist.
Design system ਸਿਰਫ਼ ਵਿਜ਼ੂਅਲ ਇਕਰੂਪਤਾ ਨਹੀਂ—ਇਹ ਵਿਹਾਰਕ ਇਕਰੂਪਤਾ ਵੀ ਹੈ। ਜਦੋ modal ਹਰ ਵਾਰੀ focus trap ਸਹੀ ਰੀਤੀ ਨਾਲ ਕਰਦਾ ਹੈ, ਜਾਂ dropdown ਹਮੇਸ਼ਾਂ keyboard navigation ਸਹਿਯੋਗੀ ਹੁੰਦਾ ਹੈ, ਤਾਂ accessibility default ਬਣ ਜਾਂਦੀ ਹੈ ਨਾ ਕਿ ਬਾਅਦ ਵਿੱਚ ਸੋਚਣ ਵਾਲੀ ਚੀਜ਼।
Theming ਵੀ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ: ਤੁਸੀਂ tokens (colors, spacing, typography) ਨੂੰ ਕੇਂਦਰੀਕ੍ਰਿਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ components ਉਹਨਾਂ ਨੂੰ ਇਸਤੇਮਾਲ ਕਰਦੇ ਹਨ, ਤਾਂ brand changes ਲਈ ਹਰ ਸਕ੍ਰੀਨ 'ਤੇ ਹੱਥ ਮੁਲ੍ਹ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਘੱਟ ਹੋ ਜਾਂਦੀ ਹੈ।
ਜਿਨ੍ਹਾਂ ਟੀਮਾਂ ਨੂੰ shared components ਵਿੱਚ ਨਿਵੇਸ਼ ਕਰਨ ਦੀ ਲਗਨ ਹੋਵੇ, ਉਹ ਅਕਸਰ ਇਸ ਫੈਸਲੇ ਨੂੰ scale ਅਤੇ maintenance ਖਰਚਾਂ ਨਾਲ ਜੋੜਦੇ ਹਨ; ਕੁਝ organizations ਇਸ ਮੁਲਾਂਕਣ ਨੂੰ platform ਯੋਜਨਾਵਾਂ (ਜਿਵੇਂ /pricing) ਨਾਲ ਜੁੜਦੇ ਦੇਖਦੀਆਂ ਹਨ।
React ਸਿਰਫ਼ UI ਬਣਾਉਣ ਦਾ ਤਰੀਕਾ ਨਹੀਂ ਬਦਲਿਆ—ਇਸ ਨੇ ਗੁਣਵੱਤਾ ਨਾਪਣ ਦੇ ਤਰੀਕੇ ਨੂੰ ਵੀ ਬਦਲ ਦਿੱਤਾ। ਜਦ ਤੁਹਾਡੀ ਐਪ components ਨਾਲ ਬਣੀ ਹੁੰਦੀ ਹੈ ਜੋ ਸਪੱਸ਼ਟ inputs (props) ਅਤੇ outputs (rendered UI) ਰੱਖਦੀਆਂ ਹਨ, ਤਾਂ ਟੈਸਟਿੰਗ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਆਰਕੀਟੈਕਚਰਕ ਫੈਸਲੇ ਬਣ ਜਾਂਦੇ ਹਨ, ਨ ਕਿ ਆਖ਼ਰੀ-ਸਮੇਂ ਦੇ ਠੀਕ-ਥੀਕ ਕਰਵਾ ਦੇ।
Component ਸਰਹੱਦ ਤੁਹਾਨੂੰ ਦੋ ਲਾਭਦਾਇਕ ਪੱਧਰਾਂ ਤੇ ਟੈਸਟ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ:
ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ components ਦੀ clear ownership ਹੋਵੇ: ਇੱਕ ਜਗ੍ਹਾ ਜੋ state ਦੀ ਮਾਲਕੀ ਕਰਦੀ ਹੈ, ਅਤੇ children ਜੋ ਮੁੱਖ ਤਾਂ display ਕਰਦੇ ਅਤੇ event emit ਕਰਦੇ ਹਨ।
React ਐਪ ਅਕਸਰ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਟੀਮਾਂ performance ਨੂੰ structure ਵਿੱਚ ਹੀ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸੋਚਦੀਆਂ ਹਨ:
ਇੱਕ ਵਰਤਣਯੋਗ ਨਿਯਮ: ਮਹਿੰਗੇ ਹਿੱਸਿਆਂ (large lists, complex calculations, ਅਤੇ ਬਾਰ-ਬਾਰ re-render ਹੋਣ ਵਾਲੇ ਹਿੱਸੇ) ਨੂੰ optimize ਕਰੋ, ਨਾ ਕਿ ਛੋਟੀਆਂ ਚੀਜ਼ਾਂ ਲਈ ਪਿੱਛੇ ਪੜੋ।
ਸਮੇਂ ਦੇ ਨਾਲ, ਟੀਮਾਂ ਆਮ ਫੱਲ-ਆਉਟ ਵਿੱਚ ਡਿੱਬ ਸਕਦੀਆਂ ਹਨ: over-componentizing (ਬਹੁਤ ਸਾਰੇ ਛੋਟੇ ਹਿੱਸੇ ਜਿਨ੍ਹਾਂ ਦਾ ਮਕਸਦ ਨਹੀਂ), prop drilling (ਬਹੁਤ ਸਤ੍ਹਾਂ ਰਾਹੀਂ ਡੇਟਾ ਪਾਸ), ਅਤੇ unclear boundaries ਜਿੱਥੇ ਕੋਈ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਕਿਸ ਕੰਪੋਨੈਂਟ ਦੀ state “ਮਾਲਕ” ਹੈ।
ਜਦ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧ ਰਹੇ ਹੋ (ਖ਼ਾਸ ਕਰਕੇ auto-generated ਜਾਂ scaffolded ਕੋਡ ਨਾਲ), ਇਹ pitfalls ਤੇਜ਼ੀ ਨਾਲ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ: components ਵੱਧ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਮਾਲਕੀ ਧੁੰਦਲੀ ਹੋ ਜਾਂਦੀ ਹੈ। ਚਾਹੇ ਤੁਸੀਂ ਹੱਥੋਂ ਕੋਡ ਲਿਖ ਰਹੇ ਹੋ ਜਾਂ Koder.ai ਵਰਗਾ ਟੂਲ استعمال ਕਰਕੇ React ਐਪ ਅਤੇ backend (ਅਕਸਰ Go ਨਾਲ PostgreSQL) ਜਨਰੇਟ ਕਰ ਰਹੇ ਹੋ, guardrail ਇੱਕੋ ਹੀ ਰਹਿੰਦੇ: state ownership explicit ਰੱਖੋ, component APIs ਛੋਟੇ ਰੱਖੋ, ਅਤੇ clear feature boundaries ਵੱਲ refactor ਕਰੋ।
Server Components, meta-frameworks, ਅਤੇ ਹੋਰ ਬਿਹਤਰ ਟੂਲਿੰਗ React ਐਪਾਂ ਦੇ ਡਿਲਿਵਰੀ ਤਰੀਕੇ ਨੂੰ ਬਦਲਦੇ ਰਹਿਣਗੇ। ਲੰਬੇ ਸਮੇਂ ਲਈ ਸਬਕ ਬਦਲਿਆ ਨਹੀਂ: state, ownership, ਅਤੇ composable UI ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਦੇ ਆਸ-ਪਾਸ ਡਿਜ਼ਾਈਨ ਕਰੋ, ਫਿਰ testing ਅਤੇ performance ਕੁਦਰਤੀ ਤਰੀਕੇ ਨਾਲ ਆਉਣਗੇ।
ਵਧੇਰੇ ਢਾਂਚਾਗਤ ਫੈਸਲਿਆਂ ਲਈ, ਵੇਖੋ /blog/state-management-react.
React ਨੇ ਫਰੰਟਏਂਡ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਕੁਝ ਮੁੱਖ ਫੈਸਲਿਆਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਮੁੜ-ਪੇਸ਼ ਕੀਤਾ:
ਪ੍ਰਯੋਗਕ ਤੌਰ 'ਤੇ ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਹੱਥੋਂ-ਹੱਥ DOM ਦੀ ਮੈਥੀਨੀਕਲ ਕੰਮ-ਕਰਵਾਈ ਘਟਦੀ ਹੈ ਅਤੇ ਟੀਮਾਂ ਅਤੇ ਟੂਲਿੰਗ ਲਈ ਜ਼ਿਆਦਾ ਸਾਫ਼ ਸਰਹੱਦ ਬਣਦੇ ਹਨ।
Component thinking ਦਾ ਅਰਥ ਹੈ ਹਰ UI ਹਿੱਸੇ ਨੂੰ ਇੱਕ ਛੋਟੀ, ਮੁੜ-ਉਪਯੋਗ ਯੂਨਿਟ ਵਜੋਂ ਵੇਖਣਾ ਜੋ ਆਪਣੀ rendering ਦਾ ਮਾਲਕ ਹੁੰਦਾ ਹੈ ਅਤੇ ਵੱਡੇ ਸਕ੍ਰੀਨਾਂ ਵਿੱਚ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਪ੍ਰਯੋਗਕ ਤੌਰ 'ਤੇ ਇੱਕ component ਵਿੱਚ ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ:
ਇਹ ਸੋਚ “ਇਸ DOM ਨੋਡ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ” ਦੀ بجਾਇ “ਇਸ state ਲਈ ਇਸ component ਨੂੰ render ਕਰੋ” ਵੱਲ ਮੋੜਦੀ ਹੈ।
DOM-ਪਹਿਲਾਂ ਕੋਡ ਵਿੱਚ DOM ਅਕਸਰ ਸੱਚ ਦਾ ਸਰੋਤ ਬਣ ਜਾਂਦਾ ਸੀ, ਇਸ ਲਈ ਤੁਸੀਂ ਹੱਥੋਂ-ਹੱਥ ਕਈ ਤੱਤਾਂ ਨੂੰ ਸਿੰਕ ਵਿੱਚ ਰੱਖਦੇ ਰਹਿੰਦੇ ਸੀ। React ਵਿੱਚ, ਤੁਸੀਂ state ਅੱਪਡੇਟ ਕਰਦੇ ਹੋ ਅਤੇ UI ਉਸਦੇ ਅਨੁਸਾਰ ਰੈਂਡਰ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਲੋਡਿੰਗ ਸਪਿੰਨਰ, disabled ਬਟਨ ਅਤੇ empty states ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਸੰਗਤ ਰਹਿੰਦੇ ਹਨ।
ਇੱਕ ਅਚੱਛਾ ਲਿਟਮਸ ਟੈਸਟ: ਜੇ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰਿਆਂ “ਐਲੀਮੈਂਟ ਲੱਭੋ ਅਤੇ ਕਲਾਸ ਟੌਗਲ ਕਰੋ” ਵਾਲੀਆਂ ਕਮਾਂਡਾਂ ਲਿਖ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਮਾਡਲ ਦੇ ਖਿਲਾਫ ਲੜ ਰਹੇ ਹੋ; ਜੇ UI ਸਟੇਟ ਤੋਂ ਬਾਹਰ ਨਿਕਲਦਾ ਹੈ, ਤਾਂ ਵਾਹਦਰਤਾ ਅਕਸਰ state ownership ਦਾ ਮੁੱਦਾ ਹੁੰਦਾ ਹੈ।
React ਤੋਂ ਪਹਿਲਾਂ ਬਹੁਤ ਸਾਰੇ ਐਪ ਪੇਜ-ਕੇਂਦ੍ਰਿਤ ਸਨ: ਸਰਵਰ-ਰੈਂਡਰਡ ਟੈਂਪਲੇਟ ਅਤੇ jQuery/plugins ਨਾਲ। ਵਿਹਾਰ server views, HTML attributes ਅਤੇ JS initializers ਵਿਚ ਵੰਡਿਆ ਹੋਇਆ ਸੀ।
ਆਮ ਸਮੱਸਿਆਵਾਂ ਵਿੱਚ ਸ਼ਾਮਿਲ:
React ਨੇ ਟੀਮਾਂ ਨੂੰ ਮੁੜ-ਉਪਯੋਗ ਕੰਪੋਨੈਂਟ ਅਤੇ ਪੇਸ਼ਬੱਧ ਅੱਪਡੇਟਸ ਵੱਲ ਧਕੇਲਿਆ।
Declarative rendering ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਸੀਂ ਕਿਸੇ ਦਿੱਤੇ state ਲਈ UI ਨੂੰ ਕਿਵੇਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਵੇਰਵਾ ਕਰਦੇ ਹੋ, ਨਾ ਕਿ DOM ਨੂੰ ਕਦਮ-ਬਦ-ਕਦਮ ਕਿਵੇਂ ਬਦਲਣਾ ਹੈ।
ਬਦਲ ਦੀ ਥਾਂ:
ਤੁਸੀਂ ਹੀ ਕਹਿਣਾ: “ਜੇ ਯੂਜ਼ਰ ਲੌਗ ਇਨ ਹੈ ਤਾਂ ਨਾਮ ਦਿਖਾਓ, ਨਹੀਂ ਤਾਂ ‘Sign in’ ਬਟਨ” — ਅਤੇ React ਅਸਲੀ DOM ਨੂੰ ਅਪਡੇਟ ਕਰਦਾ ਹੈ।
JSX ਨੇ UI ਸਰਚਨਾ ਨੂੰ ਉਸ ਲਾਜਿਕ ਦੇ ਨੇੜੇ ਲਿਖਣਾ ਆਸਾਨ ਕੀਤਾ ਜੋ ਉਸ ਨੂੰ ਕੰਟਰੋਲ ਕਰਦੀ ਹੈ (ਸ਼ਰਤਾਂ, ਫਾਰਮੇਟਿੰਗ, ਹੈਂਡਲਰ). ਇਸ ਨਾਲ template ਅਤੇ logic ਫਾਇਲਾਂ ਦੇ ਵਿਚਕਾਰ ਘੁੰਮਣ ਦੀ ਲੋੜ ਘੱਟ ਹੋ ਗਈ।
JSX HTML ਨਹੀਂ—ਇਹ ਜਾਵਾਸਕ੍ਰਿਪਟ ਕਾਲਾਂ ਬਣਾਉਂਦਾ ਹੈ। ਪਰ ਖਾਸ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਉਹ ਚੀਜ਼ਾਂ ਜੋ ਇਕੱਠੇ ਬਦਲਦੀਆਂ ਹਨ (UI + ਬਿਹੇਵਿਯਰ) ਇਕ ਹੀ ਥਾਂ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਜੋ ਰਖ-ਰਖਾਅ ਲਈ ਆਮ ਤੌਰ 'ਤੇ ਸਾਫ਼ ਹੁੰਦਾ ਹੈ।
Reconciliation ਉਹ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜਿਸ ਵਿੱਚ React ਪਿਛਲੇ render ਨਤੀਜੇ ਨੂੰ ਨਵੇਂ ਨਾਲ ਤੁਲਨਾ ਕਰਦਾ ਹੈ ਅਤੇ DOM ਨੂੰ ਸੁਘੜ ਤਰੀਕੇ ਨਾਲ ਅਪਡੇਟ ਕਰਦਾ ਹੈ।
ਮੁੱਖ ਨੁਕਤਾ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ render ਲੋਜਿਕ ਨੂੰ “ਜਿਵੇਂ” ਦੁਬਾਰਾ ਬਣਾਉਂਦੇ ਹੋ ਉਸੇ ਤਰ੍ਹਾਂ ਲਿਖ ਸਕਦੇ ਹੋ, ਅਤੇ React incremental ਤੌਰ 'ਤੇ ਅਪਡੇਟ ਕਰਦਾ ਹੈ।
ਲਿਸਟਾਂ ਲਈ practical ਗੱਲ: key ਦੀ ਵਰਤੋਂ ਕਰੋ ਜੋ stable ਅਤੇ unique ਹੋ (ਜਿਵੇਂ ID). ਜੇ items reorder/insert/delete ਹੋ ਸਕਦੇ ਹਨ ਤਾਂ ਆਰੇ ਇੰਡੈਕਸ ਵਰਤਣਾ ਸਹੀ ਨਹੀਂ—ਇੱਸ ਨਾਲ ਗਲਤ component instance reuse ਹੋ ਸਕਦੀ ਹੈ (ਉਦਾਹਰਨ ਵਜੋਂ inputs ਗਲਤ value ਰੱਖ ਲੈਂਦੇ ਹਨ)।
One-way data flow ਵਿੱਚ ਡੇਟਾ ਮਾਪੇ-ਕੰਪੋਨੈਂਟ ਤੋਂ ਬੱਚੇ ਤੱਕ props ਰਾਹੀਂ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਬੱਚੇ ਬਦਲਾਅ ਦੀ ਬੇਨਤੀ callbacks ਰਾਹੀਂ ਕਰਦੇ ਹਨ.
ਇਸ ਨਾਲ ਸਰਹੱਦ ਸਪੱਸ਼ਟ ਹੁੰਦੀ ਹੈ:
Debugging ਆਮ ਤੌਰ 'ਤੇ “state ਕਿੱਥੇ ਹੈ” ਲੱਭਣ ਬਣ ਜਾਂਦਾ ਹੈ ਬਜਾਏ ਕਿ ਛੁਪੇ ਹੋਏ mutations ਦੀ ਖੋਜ ਕਰਨ ਦੇ।
Composition ਦਾ ਅਰਥ ਹੈ ਕਿ ਤੁਸੀਂ UI ਨੂੰ ਛੋਟੇ, ਫੋਕਸਡ ਹਿੱਸਿਆਂ ਨੂੰ ਮਿਲਾ ਕੇ ਬਣਾਉਂਦੇ ਹੋ ਬਜਾਏ ਕਿਸੇ ਕਿਸੇ base class ਨੂੰ ਵਧਾਉਣ ਦੇ।
ਰੋਜ਼ਮਰ੍ਹਾ ਉਦਾਹਰਨਾਂ:
ਇਕ ਪ੍ਰਯੋਗਕ ਤਰਤੀਬ ਹੈ:
ਚੋਣ ਐਪ ਦੀ complexity, ਟੀਮ ਦੇ ਆਕਾਰ ਅਤੇ ਬਦਲਾਅ ਦੀ ਤੀਵ੍ਰਤਾ ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ—ਫੈਸ਼ਨ ਨਹੀਂ।
children ਸਵੀਕਾਰ ਕਰਦੇ ਹਨ (PageShell, Stack/Grid, Card)RequireAuth ਜਾਂ ErrorBoundarytitle, footer, emptyState) ਜਦੋਂ children ਕਾਫੀ ਨਾ ਹੋਵੇਇਹ inheritance ਵਾਲੇ ਡੂੰਘੇ ਦਰੱਖਤਾਂ ਦੀ ਬਜਾਏ ਸਾਦਾ ਅਤੇ ਉਪਯੋਗੀ API ਪੇਸ਼ ਕਰਦਾ ਹੈ।