ਕਿਵੇਂ React ਨੇ ਫਰੰਟਐਂਡ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਕੰਪੋਨੈਂਟਸ ਨਾਲ ਬਦਲਿਆ

React ਦੇ ਆਉਣ ਨਾਲ ਕੀ ਬਦਲਿਆ

React ਸਿਰਫ਼ ਇੱਕ ਨਵਾਂ ਲਾਇਬਰੇਰੀ ਨਹੀਂ ਲਿਆਉਂਦਾ—ਇਸ ਨੇ ਇਹ ਬਦਲ ਦਿੱਤਾ ਕਿ ਟੀਮਾਂ “frontend architecture” ਨਾਲ ਕੀ ਮਤਲਬ ਮੰਨਦੀਆਂ ਹਨ। ਅਮਲ ਵਿੱਚ, frontend architecture ਉਹ ਫੈਸਲੇ ਹਨ ਜੋ UI ਕੋਡਬੇਸ ਨੂੰ ਸਕੇਲ 'ਤੇ ਸਮਝਣਯੋਗ ਰੱਖਦੇ ਹਨ: ਤੁਸੀਂ UI ਨੂੰ ਕਿਵੇਂ ਭਾਗਾਂ ਵਿੱਚ ਵੰਡਦੇ ਹੋ, ਡੇਟਾ ਉਹਨਾਂ ਵਿੱਚ ਕਿਵੇਂ ਜਾਂਦੀ ਹੈ, state ਕਿੱਥੇ ਰਹਿੰਦੀ ਹੈ, side effects (ਜਿਵੇਂ ਡੇਟਾ ਫੈਚ ਕਰਨਾ) ਕਿਵੇਂ ਹੇਠਾਂ ਲਿਆਂਦੇ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਨਤੀਜੇ ਨੂੰ ਟੀਮ-ਵਿਚਾਰਯੋਗ ਅਤੇ ਟੈਸਟੇਬਲ ਕਿਵੇਂ ਰੱਖਦੇ ਹੋ।

ਇਕ ਵਾਕ ਵਿੱਚ component ਸੋਚ

Component thinking ਹਰ UI ਹਿੱਸੇ ਨੂੰ ਇੱਕ ਛੋਟੀ, ਮੁੜ-ਉਪਯੋਗ ਯੂਨਿਟ ਵਜੋਂ ਦੇਖਣਾ ਹੈ ਜੋ ਆਪਣੀ rendering ਦਾ ਮਾਲਕ ਹੈ ਅਤੇ ਹੋਰ ਯੂਨਿਟਾਂ ਨਾਲ ਜੋੜ ਕੇ ਪੂਰੇ ਪੇਜ਼ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।

ਉਹ ਬਦਲਾਵ ਜੋ React ਨੇ ਜਨਮ ਦਿੱਤਾ

React ਦੇ ਮਸ਼ਹੂਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਬਹੁਤ ਪ੍ਰੋਜੈਕਟ ਪੇਜ਼ ਅਤੇ DOM ਮੈਨਿਪੂਲੇਸ਼ਨ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸੰਗਠਿਤ ਹੁੰਦੇ ਸਨ: “ਇਸ ਐਲੀਮੈਂਟ ਨੂੰ ਲੱਭੋ, ਇਸ ਦਾ ਟੈਕਸਟ ਬਦਲੋ, ਇਸ ਕਲਾਸ ਨੂੰ ਟੌਗਲ ਕਰੋ।” React ਨੇ ਟੀਮਾਂ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਡੀਫੋਲਟ ਵੱਲ ਧੱਕਿਆ:

• State-driven UI: ਤੁਸੀਂ state ਅੱਪਡੇਟ ਕਰਦੇ ਹੋ, ਅਤੇ UI ਆਪਣੇ ਆਪ ਅਪਡੇਟ ਹੋ ਜਾਂਦੀ ਹੈ।
• Composition over wiring: ਤੁਸੀਂ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਕੰਪੋਨੈਂਟ ਨਾਲ nested ਅਤੇ combine ਕਰਕੇ ਬਣਾਉਂਦੇ ਹੋ ਬਜਾਏ ਕਿ ਬਿਹੇਵਿਯਰ ਨੂੰ ਅਲੱਗ-ਅਲੱਗ ਫਾਈਲਾਂ ਵਿੱਚ ਸੀਲ੍ਹਾ ਕਰਨ ਦੇ।
• Reuse as a first-class goal: ਸਾਂਝੇ UI ਪੈਟਰਨ ਹੁਣ components ਬਣ ਜਾਂਦੇ ਹਨ ਨਾ ਕਿ copied markup।

ਇਹ ਵਿਚਾਰ ਰੋਜ਼ਾਨਾ ਦੇ ਕੰਮ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ। ਕੋਡ ਰਿਵਿਊਜ਼ ਹੁਣ ਪੁੱਛਣ ਲੱਗੇ “ਇਹ state ਕਿੱਥੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ?” ਨਾ ਕਿ “ਤੁਸੀਂ ਕਿਸ selector ਦੀ ਵਰਤੋਂ ਕੀਤੀ?” ਡਿਜ਼ਾਈਨਰ ਅਤੇ ਇੰਜੀਨੀਅਰ ਇੱਕ ਸਾਂਝੇ component ਵਾਕ-ਪਦ ਨੂੰ ਸਮਝ ਸਕਦੇ ਸਨ, ਅਤੇ ਟੀਮਾਂ UI ਬਲੌਕਾਂ ਦੀਆਂ ਲਾਇਬਰੇਰੀਆਂ ਵਧਾ ਸਕਦੀਆਂ ਸਨ ਬਿਨਾਂ ਪੂਰੇ ਪੇਜ਼ ਦੁਬਾਰਾ ਲਿਖਣ ਦੇ।

React ਤੋਂ ਵੱਡਾ ਪ੍ਰਭਾਵ

ਐਨਾ ਹੀ ਨਹੀਂ ਕਿ ਜੇ ਟੀਮ ਬਾਅਦ ਵਿੱਚ ਹੋਰ ਫਰੇਮਵਰਕ 'ਤੇ ਚਲੀ ਵੀ ਜਾਂਦੀ ਹੈ, React-ਦਿੱਤੇ ਗਏ ਆਦਤਾਂ ਬਹੁਤ ਦਿਨ ਤੱਕ ਰਹਿੰਦੇ ਹਨ: ਕੰਪੋਨੈਂਟ-ਅਧਾਰਿਤ ਆਰਕੀਟੈਕਚਰ, declarative rendering, predictable data flow, ਅਤੇ design system ਦੇ ਮੁੜ-ਉਪਯੋਗ ਕੰਪੋਨੈਂਟਾਂ ਦੀ ਪਸੰਦ। React ਨੇ ਇਹ ਪੈਟਰਨ ਆਮ ਕਰ ਦਿੱਤੇ—ਅਤੇ ਇਸ ਨੇ ਵਿਆਪਕ ਫਰੰਟਐਂਡ ਪਰਿਵੇਸ਼ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ।

React ਤੋਂ ਪਹਿਲਾਂ: ਪੇਜ-ਕੇਂਦ੍ਰਿਤ UI ਅਤੇ DOM-ਪਹਿਲਾਂ ਕੋਡ

React ਤੋਂ ਪਹਿਲਾਂ, ਬਹੁਤ ਟੀਮਾਂ ਇੰਟਰਫੇਸ ਨੂੰ ਪੇਜ਼ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਬਣਾਉਂਦੀਆਂ ਸਨ, ਨਾ ਕਿ ਮੁੜ-ਉਪਯੋਗ UI ਯੂਨਿਟਾਂ ਦੇ। ਆਮ ਸੈਟਅੱਪ ਸਰਵਰ-ਰੈਂਡਰਡ ਟੈਂਪਲੇਟ (PHP, Rails, Django, JSP ਆਦਿ) ਹੋ ਸਕਦਾ ਸੀ ਜੋ HTML ਤਿਆਰ ਕਰਦਾ ਸੀ, ਅਤੇ ਉੱਪਰ jQuery ਤੜਕਾ ਹੁੰਦਾ ਸੀ ਇੰਟਰਐਕਟਿਵਿਟੀ ਲਈ।

ਆਮ stack: templates + jQuery + plugins

ਤੁਸੀਂ ਇੱਕ ਪੇਜ਼ ਰੈਂਡਰ ਕਰਦੇ, ਫਿਰ ਉਸਨੂੰ ਸਕ੍ਰਿਪਟਾਂ ਨਾਲ “ਸਕ੍ਰਿਯੇਟ” ਕਰਦੇ: datepickers, modal plugins, form validators, carousels—ਹਰੇਕ ਦੀ ਆਪਣੀ markup ਉਮੀਦਾਂ ਅਤੇ event hooks ਹੁੰਦੀਆਂ।

ਕੋਡ ਅਕਸਰ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗਦਾ: DOM ਨੋਡ ਲੱਭੋ, handler ਜੋੜੋ, DOM ਨੂੰ mutate ਕਰੋ, ਅਤੇ ਆਸ ਕਰੋ ਕਿ ਹੋਰ ਕੁਝ ਤੋੜੇ ਨਾ। ਜਿਵੇਂ ਜਿਵੇਂ UI ਵਧਦਾ ਗਿਆ, “source of truth” ਚੁੱਪਚਾਪ DOM ਖੁਦ ਬਣ ਗਿਆ।

ਵਿਹਾਰ ਪਰਤਾਂ ਵਿੱਚ ਵਿਖਰਿਆ ਹੋਇਆ

UI ਵਿਹਾਰ ਕਈ ਵਾਰ ਇੱਕ ਥਾਂ ਨਹੀਂ ਰਹਿੰਦਾ ਸੀ। ਇਹ ਵੰਡਿਆ ਹੋਇਆ ਸੀ:

• Server views (conditional rendering, partials, feature flags)
• HTML (data-* attributes, inline handlers, hidden fields)
• JavaScript (jQuery selectors, global state, plugin initialization)

ਇੱਕ single widget—ਜਿਵੇਂ checkout summary—ਦੀ ਤਿਆਰੀ ਹਿਸੇ-ਹਿਸੇ ਸਰਵਰ ਤੇ ਹੁੰਦੀ, AJAX ਨਾਲ ਅੱਪਡੇਟ ਹੁੰਦੀ, ਅਤੇ plugin ਨਾਲ ਨਿਯੰਤਰਿਤ ਹੁੰਦੀ।

ਆਮ ਦਰਦ-ਬਿੰਦੂ

ਇਹ ਢੰਗ ਛੋਟੇ enhancements ਲਈ ਕੰਮ ਕਰਦਾ ਸੀ, ਪਰ ਇਹ ਮੁੜ-ਮੁੜ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰਦਾ:

• Duplicated UI: ਇਕੋ “component” ਕਈ templates ਅਤੇ pages ਵਿੱਚ ਦੁਬਾਰਾ ਬਣਾਈ ਜਾਂਦੀ
• Inconsistent state: loading spinners, disabled buttons, ਅਤੇ error messages sync ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਂਦੇ
• Fragile DOM code: ਛੋਟੇ ਮਾਰਕਅਪ ਬਦਲਾਅ ਨਾਲ selectors ਅਤੇ event wiring ਟੁੱਟ ਜਾਂਦੇ

ਸ਼ੁਰੂਆਤੀ MV* ਇਕ ਬ੍ਰਿਜ ਵਜੋਂ

ਲਾਇਬਰੇਰੀਆਂ ਜਿਵੇਂ Backbone, AngularJS, ਅਤੇ Ember models, views, ਅਤੇ routing ਨਾਲ ਢਾਂਚਾ ਲਿਆਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ—ਅਕਸਰ ਇਹ ਵੱਡੀ ਸੁਧਾਰ ਸੀ। ਪਰ ਬਹੁਤ ਟੀਮਾਂ ਹਜੇ ਵੀ ਪੈਟਰਨ ਮਿਲਾਉਂਦੀਆਂ ਰਹੀਆਂ, ਜਿਸ ਨਾਲ UI ਨੂੰ ਦੁਹਰਾਉਣਯੋਗ ਯੂਨਿਟਾਂ ਵਜੋਂ ਬਿਲਡ ਕਰਨ ਲਈ ਇੱਕ ਸਾਫ਼ ਤੇ ਸਿੰਪਲ ਤਰੀਕੇ ਦੀ ਲੋੜ ਰਹੀ।

ਵੱਡਾ ਖਿਆਲ: UI ਇੱਕ state ਦਾ ਫੰਕਸ਼ਨ ਹੈ

React ਦਾ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਬਦਲਾਅ ਆਖਣ ਵਿੱਚ ਸਿੱਧਾ ਅਤੇ ਅਮਲ ਵਿੱਚ ਹੈਰਾਨੀਜਨਕ ਤੌਰ 'ਤੇ ਸ਼ਕਤੀਸ਼ালী ਹੈ: UI state ਦਾ ਫੰਕਸ਼ਨ ਹੈ। DOM ਨੂੰ “source of truth” ਮੰਨਣ ਅਤੇ ਇਸਨੂੰ ਮੈਨੁਅਲੀ ਤੌਰ 'ਤੇ ਸਿੰਕ ਰੱਖਣ ਦੀ ਬਜਾਏ, ਤੁਸੀਂ ਆਪਣਾ ਡੇਟਾ ਸਰੋਤ-ਏ-ਸੱਚ ਮੰਨਦੇ ਹੋ ਅਤੇ UI ਨੂੰ ਨਤੀਜੇ ਵਜੋਂ ਛੱਡ ਦਿੰਦੇ ਹੋ।

ਰੋਜ਼ਾਨਾ ਐਪਸ ਵਿੱਚ “state” ਦਾ ਕੀ ਮਤਲਬ ਹੈ

State ਸਿਰਫ ਉਹ ਮੌਜੂਦਾ ਡੇਟਾ ਹੈ ਜਿਸ 'ਤੇ ਤੁਹਾਡੀ ਸਕ੍ਰੀਨ ਨਿਰਭਰ ਕਰਦੀ ਹੈ: ਕੀ ਮੈਨੂ ਖੁੱਲ੍ਹਾ ਹੈ, ਫਾਰਮ ਵਿੱਚ ਕੀ ਟਾਈਪ ਕੀਤਾ ਗਿਆ ਹੈ, ਕਿਸ ਆਈਟਮ ਦੀ ਸੂਚੀ ਹੈ, ਕਿਹੜਾ filter ਚੁਣਿਆ ਗਿਆ ਹੈ।

ਜਦੋਂ state ਬਦਲਦੀ ਹੈ, ਤੁਸੀਂ ਪੇਜ਼ 'ਚ ਕਈ DOM ਨੋਡ ਖੋਜ ਕੇ ਅਪਡੇਟ ਨਹੀਂ ਕਰਦੇ। ਤੁਸੀਂ state ਅਪਡੇਟ ਕਰਦੇ ਹੋ, ਅਤੇ UI ਉਸ ਦੇ ਅਨੁਕੂਲ ਰੈਂਡਰ ਹੋ ਜਾਂਦੀ ਹੈ।

ਇਹ ਮੈਨੁਅਲ DOM ਕੰਮ ਘਟਾਉਂਦਾ ਕਿਵੇਂ

ਪारੰਪਰਿਕ DOM-ਪਹਿਲਾਂ ਕੋਡ ਅਕਸਰ ਵਿਖਰਿਆ ਹੋਇਆ update logic ਪੈਦਾ ਕਰਦਾ ਸੀ:

• checkbox ਬਦਲੋ → label ਅਪਡੇਟ ਕਰੋ
• item ਜੋੜੋ → list ਅਤੇ empty-state message ਅਪਡੇਟ ਕਰੋ
• form ਸਬਮਿਟ ਕਰੋ → button disable ਕਰੋ, spinner ਦਿਖਾਓ, errors ਸੰਭਾਲੋ

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 ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ

ਇੱਕ ਪ੍ਰਯੋਗਕ component ਆਮ ਤੌਰ 'ਤੇ ਸ਼ਾਮਿਲ ਹੁੰਦਾ ਹੈ:

• Structure (ਉਹ ਕੀ ਰੈਂਡਰ ਕਰਦਾ ਹੈ)
• Interaction (handlers, state, effects)
• Styling hooks (class names, variants, tokens)

ਮੁੱਖ ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ “ਇਸ div ਨੂੰ ਅਪਡੇਟ ਕਰੋ” ਦੀ ਸੋਚ ਛੱਡ ਦਿੰਦੇ ਹੋ ਅਤੇ “ਇਸ Button ਨੂੰ ਉਸ ਦੇ disabled state ਵਿੱਚ render ਕਰੋ” ਦੀ ਸੋਚ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ।

Encapsulation = ਅਸਾਨ ਮੁਰੰਮਤ ਅਤੇ ਸਪਸ਼ਟ ਮਾਲਕੀ

ਜਦੋਂ ਇੱਕ component ਥੋੜ੍ਹੇ props (inputs) ਅਤੇ events/callbacks (outputs) ਨੂੰ ਖੋਲ੍ਹਦਾ ਹੈ, ਤਾਂ ਇਸ ਦੇ ਅੰਦਰਲੇ ਹਿੱਸਿਆਂ ਨੂੰ ਬਦਲਣਾ ਬਿਨਾਂ ਬਾਕੀ ਐਪ ਨੂੰ ਤੋੜੇ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ। ਟੀਮਾਂ ਵਿਸ਼ੇਸ਼ components ਜਾਂ ਫੋਲਡਰ (ਉਦਾਹਰਨ ਲਈ, “checkout UI”) ਦੀ ਮਾਲਕੀ ਲੈਂਦੀਆਂ ਹਨ ਅਤੇ ਨਿਰਭਿੱਕ ਹੋ ਕੇ ਸੁਧਾਰ ਕਰ ਸਕਦੀਆਂ ਹਨ।

Encapsulation ਨਾਲ accidental coupling ਘਟਦਾ ਹੈ: ਘੱਟ global selectors, ਘੱਟ cross-file side effects, ਘੱਟ “ਇਹ click handler ਕਿਉਂ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰ ਗਿਆ?” ਵਾਲੀਆਂ ਚੌਕਾਂ।

Components ਪ੍ਰੋਡਕਟ ਸੰਕਲਪਾਂ ਨਾਲ ਮਿਲਦੇ ਹਨ

ਜਿਵੇਂ ਹੀ components ਮੁੱਖ ਬਿਲਡਿੰਗ ਬਲਾਕ ਬਣੇ, ਕੋਡ ਪ੍ਰੋਡਕਟ ਦੇ ਨਕਸ਼ੇ ਨੂੰ ਦਰਸਾਉਣ ਲੱਗਾ:

• Button (primary/secondary, loading, icon)
• Modal (open/close, focus trap, escape key)
• CheckoutForm (validation, submission, error states)

ਇਹ ਮੇਲ UI ਗੱਲਬਾਤ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ: ਡਿਜ਼ਾਈਨਰ, PM, ਅਤੇ ਇੰਜੀਨੀਅਰ ਇਕੋ “ਚੀਜ਼ਾਂ” ਬਾਰੇ ਗੱਲ ਕਰ ਸਕਦੇ ਹਨ।

ਫਾਈਲ ਸਧਾਂਤ 'ਤੇ ਪ੍ਰਭਾਵ

Component ਸੋਚ ਨੇ ਬਹੁਤ ਸਾਰੇ ਕੋਡਬੇਸ ਨੂੰ feature- ਜਾਂ domain-ਅਧਾਰਿਤ ਰੰਗ-ਰੂਪ ਦੀ ਓਰ ਧੱਕਿਆ (ਉਦਾਹਰਨ: /checkout/components/CheckoutForm) ਅਤੇ ਸਾਂਝੀ UI ਲਾਇਬਰੇਰੀਆਂ (/ui/Button) ਵੱਲ। ਜਦ ਫੀਚਰ ਵਧਦੇ ਹਨ, ਇਹ ਢਾਂਚਾ ਪੇਜ-ਕੇਵਲ ਫੋਲਡਰਾਂ ਨਾਲੋਂ ਬਿਹਤਰ ਸਕੇਲ ਕਰਦਾ ਹੈ ਅਤੇ design systems ਲਈ ਮੰਚ ਤਿਆਰ ਕਰਦਾ ਹੈ।

Declarative rendering ਅਤੇ JSX ਨੇ ਇਹ ਕਿਉਂ ਮਜ਼ਬੂਤ ਕੀਤਾ

React ਦੀ rendering estilo ਨੂੰ ਅਕਸਰ declarative ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਜਿਨ੍ਹਾਂ ਦਾ ਸਧਾਰਨ ਮਤਲਬ ਹੈ: ਤੁਸੀਂ ਦੱਸਦੇ ਹੋ ਕਿ ਕਿਸ ਹਾਲਤ ਵਿੱਚ UI ਕਿਵੇਂ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ React ਬਰਾਉਜ਼ਰ ਨੂੰ ਇਸਨੂੰ ਮਿਲਾਉਣ ਲਈ ਜਿੱਦੀਆਂ ਲੋੜੀਂਦੀਆਂ ਚੀਜ਼ਾਂ ਹੋਣਗੀਆਂ ਉਹ ਕਰਦਾ ਹੈ।

“ਅੰਤ ਨਤੀਜਾ ਵੇਖਾਓ, ਕਦਮ ਨਹੀਂ ਦਰਸਾਓ”

ਪੁਰਾਣੀਆਂ DOM-ਪਹਿਲਾਂ ਪਹੁੰਚਾਂ ਵਿੱਚ ਤੁਸੀਂ ਅਕਸਰ ਕਦਮ-ਬਦ-ਕਦਮ ਹਦਾਇਤਾਂ ਲਿਖਦੇ:

• element ਲੱਭੋ
• ਨਵਾਂ node ਬਣਾਓ
• ਇਸਦਾ text ਸੈੱਟ ਕਰੋ
• append ਕਰੋ
• ਬਾਅਦ ਵਿੱਚ ਅਪਡੇਟ ਜਾਂ ਹਟਾਓ

Declarative rendering ਵਿੱਚ, ਤੁਸੀਂ ਨਤੀਜੇ ਦਾ ਵਰਣਨ ਕਰਦੇ ਹੋ:

ਜੇ ਯੂਜ਼ਰ ਲੌਗਿਨ ਹੈ, ਤਾਂ ਉਸਦਾ ਨਾਮ ਦਿਖਾਓ; ਨਹੀਂ ਤਾਂ “Sign in” ਬਟਨ ਦਿਖਾਓ।

ਇਹ ਬਦਲਾਅ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ “UI bookkeeping” ਦੀ ਮਾਤਰਾ ਘਟਾਂਦਾ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਕਰਨੀਆਂ ਪੈਂਦੀਆਂ ਸਨ। ਤੁਸੀਂ ਲਗਾਤਾਰ ਇਹ ਨਹੀਂ ਟ੍ਰੈਕ ਕਰ ਰਹੇ ਕਿ ਕਿਹੜੇ ਐਲੀਮੈਂਟ ਮੌਜੂਦ ਹਨ ਅਤੇ ਕੀ ਅਪਡੇਟ ਹੋਣਾ ਚਾਹੀਦਾ—ਤੁਸੀਂ ਅਪਣੇ ਐਪ ਦੇ states 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਦੇ ਹੋ।

JSX ਨੇ ਇਸਨੂੰ ਕਿਉਂ ਫੈਲਾਇਆ

JSX ਇਕ ਸੁਵਿਧਾਜਨਕ ਤਰੀਕਾ ਹੈ UI ਸਰਚਨਾ ਨੂੰ ਉਸ ਲਾਜਿਕ ਦੇ ਨੇੜੇ ਲਿਖਣ ਦਾ ਜੋ ਇਸਨੂੰ ਕੰਟਰੋਲ ਕਰਦੀ ਹੈ। template ਫਾਈਲਾਂ ਅਤੇ logic ਫਾਈਲਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਰੱਖਣ ਦੇ ਬਦਲੇ, ਤੁਸੀਂ ਸੰਬੰਧਤ ਹਿੱਸੇ ਇਕੱਠੇ ਰੱਖ ਸਕਦੇ ਹੋ: markup-ਜੈਸੀ ਬਣਤਰ, ਸ਼ਰਤਾਂ, ਛੋਟੇ formatting ਫੈਸਲੇ, ਅਤੇ event handlers।

ਇਹ co-location ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹੈ ਕਿ React ਦਾ component ਮਾਡਲ عملي ਮਹਿਸੂਸ ਹੋਇਆ। ਇੱਕ component ਸਿਰਫ HTML ਦਾ ਟੁਕੜਾ ਜਾਂ JavaScript ਦਾ ਬੰਡਲ ਨਹੀਂ—ਇਹ UI ਵਿਹਾਰ ਦੀ ਇੱਕ ਯੂਨਿਟ ਹੈ।

“ਕੀ ਇਹ HTML ਅਤੇ JS ਮਿਲਾ ਰਹੀ ਹੈ?”

ਲੋਕਾਂ ਨੂੰ ਖ਼ਿਆਲ ਆਉਂਦਾ ਹੈ ਕਿ JSX HTML ਅਤੇ JavaScript ਨੂੰ ਮਿਲਾ ਰਿਹਾ ਹੈ, ਜੋ ਪਿੱਛੇ ਵਧਣ ਵਰਗਾ ਲੱਗਦਾ ਹੈ। ਪਰ JSX ਅਸਲ ਵਿੱਚ HTML ਨਹੀਂ ਹੈ—ਇਹ syntax ਹੈ ਜੋ JavaScript ਕਾਲਾਂ ਪੈਦਾ ਕਰਦਾ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ React ਤਕਨੀਕਾਂ ਨੂੰ ਮਿਲਾ ਰਿਹਾ ਨਹੀਂ, ਬਲਕਿ ਉਹ ਚੀਜ਼ਾਂ ਜੋ ਇਕੱਠੇ ਬਦਲਦੀਆਂ ਹਨ ਉਹਨਾਂ ਨੂੰ ਇਕੱਠੇ ਰੱਖ ਰਿਹਾ ਹੈ।

ਲਾਜ਼ਮੀ ਨਹੀਂ ਕਿ JSX ਹੀ declarative rendering ਦਾ ਇਕੱਲਾ ਰਸਤਾ ਹੈ—ਤੁਸੀਂ React ਬਿਨਾਂ JSX ਦੇ ਵੀ ਲਿੱਖ ਸਕਦੇ ਹੋ, ਅਤੇ ਹੋਰ ਫਰੇਮਵਰਕ ਵੀ declarative rendering ਵਰਤਦੇ ਹਨ। ਮੁੱਖ ਪ੍ਰਭਾਵ ਇਹ ਮਾਨਸਿਕਤਾ ਰਹਿੰਦੀ ਹੈ: UI ਨੂੰ state ਦਾ ਫੰਕਸ਼ਨ ਮੰਨੋ ਅਤੇ framework ਨੂੰ ਸਕ੍ਰੀਨ ਨੂੰ ਸਿੰਕ ਰੱਖਣ ਦੀ ਮਿਹਨਤ ਸੌਂਪੋ।

Reconciliation ਅਤੇ Virtual DOM (ਮਿਥਾਂ ਤੋਂ ਬਿਨਾਂ)

React ਤੋਂ ਪਹਿਲਾਂ, ਆਮ ਬੱਗ ਇਸ ਕਾਰਨ ਹੁੰਦੇ ਸਨ: ਡੇਟਾ ਬਦਲ ਗਿਆ ਪਰ UI ਨਹੀਂ। ਡਿਵੈਲਪਰ ਨਵਾਂ ਡੇਟਾ ਫੈਚ ਕਰਦਾ, ਫਿਰ ਹੱਥੋਂ-ਹੱਥ ਠੀਕ DOM ਨੋਡ ਲੱਭ ਕੇ ਟੈਕਸਟ ਅਪਡੇਟ ਕਰਦੇ, ਕਲਾਸ ਟੌਗਲ ਕਰਦੇ, ਐਲੀਮੈਂਟ ਜੋੜਦੇ/ਹਟਾਂਦੇ, ਅਤੇ ਇਹ ਸਭ ਕਈ ਵਾਰ ਉਦਾਹਰਣਾਂ ਤੇ ਹੀ ਭਾਰੀ ਹੋ ਜਾਂਦਾ। ਸਮੇਂ ਦੇ ਨਾਲ, “update logic” ਅਕਸਰ UI ਨਾਲੋਂ ਵੱਧ ਜਟਿਲ ਹੋ ਗਿਆ।

React ਦਾ ਵੱਡਾ workflow ਬਦਲਾਅ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ browser ਨੂੰ ਇਹ ਨਹੀਂ ਦੱਸਦੇ ਕਿ ਪੇਜ਼ ਕਿਵੇਂ ਬਦਲਣਾ ਹੈ। ਤੁਸੀਂ ਉਸ state ਲਈ UI ਦੀ ਵਰਣਨਾ ਕਰਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ React ਅਸਲੀ DOM ਨੂੰ ਮਿਲਾਉਣ ਲਈ ਕਿਹੜੇ-ਕਿਹੜੇ ਤਬਦੀਲੀਆਂ ਕਰਨੀਆਂ ਹਨ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ।

“Reconciliation” ਦਾ ਅਸਲ ਅਰਥ

Reconciliation React ਦੀ ਉਹ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜਿਸ ਵਿੱਚ ਇਹ ਤੁਲਨਾ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਪਿਛਲੇ ਵਲੋਂ ਕੀ ਰੈਂਡਰ ਕੀਤਾ ਸੀ ਅਤੇ ਹੁਣ ਕੀ ਰੈਂਡਰ ਕਰ ਰਹੇ ਹੋ, ਫਿਰ browser DOM 'ਤੇ ਘੱਟੋ-ਘੱਟ ਬਦਲਾਵ ਲਗਾਉਂਦਾ ਹੈ।

ਮੁੱਖ ਗੱਲ ਇਹ ਨਹੀਂ ਕਿ React Virtual DOM ਨੂੰ ਇੱਕ ਜਾਦੂਈ ਪਰਫਾਰਮੈਂਸ ਚਾਲਕੇ ਵਰਤਦਾ ਹੈ। ਮੈਦਾ ਹਨ ਕਿ React ਤੁਹਾਨੂੰ ਇਕ ਪਹੁੰਚ ਦਿੰਦਾ ਹੈ ਜੋ ਪੇਸ਼ਗੋਈਯੋਗ ਹੈ:

• ਤੁਸੀਂ render logic ਲਿਖਦੇ ਹੋ ਜਿਵੇਂ ਤੁਸੀਂ UI ਨੂੰ ਮੁੜ ਤਿਆਰ ਕਰ ਰਹੇ ਹੋ।
• React DOM ਨੂੰ incremental ਤਰੀਕੇ ਨਾਲ ਅਪਡੇਟ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਯੂਜ਼ਰ ਨੂੰ ਪੂਰੇ rebuild ਦਾ ਖ਼ਰਚ ਨਾ ਭੁਗਤਣਾ ਪਏ।

ਇਹ ਪੇਸ਼ਗੋਈ ਵਿਕਾਸਕਾਰਾਂ ਦੇ ਵਰਕਫਲੋ ਨੂੰ ਸੁਧਾਰਦੀ ਹੈ: ਘੱਟ ਮੈਨੁਅਲ DOM ਅਪਡੇਟ, ਘੱਟ ਅਸੰਗਤ ਸਟੇਟ, ਅਤੇ ਐਪ-ਭਰ ਇੱਕੋ ਨਿਯਮਾਂ ਅਨੁਸਾਰ UI ਅਪਡੇਟ।

Keys: ਪ੍ਰਯੋਗਕ ਨਤੀਜਾ

ਲਿਸਟਾਂ ਰੈਂਡਰ ਕਰਦੇ ਸਮੇਂ, 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 ਵਜੋਂ ਉੱਪਰ ਭੇਜਣ ਲਈ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ, ਜਦਕਿ ਨਤੀਜਾ ਡਾਟਾ ਨੀਚੇ ਵਲ ਆਉਂਦਾ ਹੈ।

ਇਕ ਸਧਾਰਣ parent/child ਉਦਾਹਰਨ

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 (ਬਦਲਾਅ ਦੀ ਮੰਗ) ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ। ਇਹ ਵੱਖਰਾ ਪਾਰਦਰਸ਼ਤਾ ਮਾਨਸਿਕ ਮਾਡਲ ਦੀ ਕੋਰ ਹੈ।

ਸਪਸ਼ਟ ਸਰਹੱਦ, ਘੱਟ side effects

ਇਹ ਪੈਟਰਨ ਸਰਹੱਦਾਂ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਉਂਦਾ ਹੈ: “ਇਹ ਡੇਟਾ ਕਿਸ ਦਾ ਹੈ?” ਦਾ ਜਵਾਬ ਆਮ ਤੌਰ 'ਤੇ “ਨਜ਼ਦੀਕੀ ਸਾਂਝਾ ਮਾਪੇ” ਹੁੰਦਾ ਹੈ। ਜਦ ਕੁਝ ਅਣ ਉਮੀਦ ਤੌਰ 'ਤੇ ਬਦਲਦਾ ਹੈ, ਤੁਸੀਂ ਉਸ ਜਗ੍ਹਾ ਤੱਕ ਟ੍ਰੇਸ ਕਰਦੇ ਹੋ ਜਿੱਥੇ state ਮੌਜੂਦ ਹੈ—ਨਹੀਂ ਤਾਂਆਂ ਛੁਪੇ mutations ਵਾਲੇ ਜਾਲ ਰਾਹੀਂ।

Props vs state ਇੱਕ ਆਰਗੇਨਾਈਜ਼ਿੰਗ ਪ੍ਰਿੰਸੀਪਲ ਵਜੋਂ

• State: ਕੰਪੋਨੈਂਟ ਦਾ ਨਿੱਜੀ, ਬਦਲਣ ਯੋਗ ਡੇਟਾ (source of truth)
• Props: ਬਾਹਰੋਂ ਦਿੱਤੇ ਇਨਪੁਟ (ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਵੱਲੋਂ read-only)

ਇਹ ਫਰਕ ਟੀਮਾਂ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਕਿ ਕਹਿਰ_logic ਕਿੱਥੇ ਹੋਵੇ ਅਤੇ ਅਕਸਮੀ coupling ਤੋਂ ਰੋਕਦਾ ਹੈ।

Reuse ਅਤੇ ਟੈਸਟਿੰਗ ਆਸਾਨ ਹੋ ਜਾਂਦੇ ਹਨ

ਜਿਹੜੇ component props 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ, ਉਹ ਮੁੜ-ਉਪਯੋਗ ਕਰਨ ਯੋਗ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ global variables ਜਾਂ DOM queries 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਹੁੰਦੇ। ਉਹਨਾਂ ਨੂੰ ਟੈਸਟ ਕਰਨਾ ਵੀ ਸਾਦਾ ਹੈ: ਤੁਸੀ ਉਹਨਾਂ ਨੂੰ ख़ਾਸ props ਦੇ ਕੇ render ਕਰੋ ਅਤੇ ਨਤੀਜੇ ਨੂੰ assert ਕਰੋ, ਜਦਕਿ stateful ਵਿਵਹਾਰ ਨੂੰ ਓਥੇ ਜਾਂਚਿਆ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ state manage ਹੁੰਦੀ ਹੈ।

ਵਾਰਸਤਾ ਦੇ ਬਜਾਏ ਰਚਨਾ: ਅਮਲਿਕ ਰੂਪ ਵਿੱਚ

React ਨੇ ਟੀਮਾਂ ਨੂੰ UI ਲਈ class hierarchies ਦੀ ਭੀੜ ਤੋਂ ਓੜ੍ਹਕੇ ਛੋਟੇ, ਕੇਂਦਰਿਤ ਟੁਕੜਿਆਂ ਨਾਲ ਸਕ੍ਰੀਨਾਂ ਨੂੰ ਜੋੜਨ ਵੱਲ ਧੱਕਿਆ। ਬਦਲੇ ਵਿੱਚ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ gedrag ਅਤੇ ਦ੍ਰਿਸ਼ਟੀ ਨੂੰ ਛੋਟੇ components ਨੂੰ ਮਿਲਾ ਕੇ ਬਣਾਉਂਦੇ ਹੋ।

ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਕੰਮ ਵਿੱਚ composition ਕਿਵੇਂ ਲੱਗਦੀ ਹੈ

ਆਮ ਪੈਟਰਨ 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, ਅਤੇ children
• Table ਨਾਲ renderRow ਜਾਂ emptyState

ਇਸ ਨਾਲ components ਲਚਕੀਲੇ ਰਹਿੰਦੇ ਹਨ ਬਿਨਾਂ API surface ਨੂੰ ਵਧਣ ਦੇ।

ਕਿਉਂ inheritance ਜ਼ਿਆਦਾਤਰ ਨੁਕਸਾਨਦਾਇਕ ਹੁੰਦੀ ਹੈ

ਗਹਿਰੀ inheritance trees ਆਮ ਤੌਰ 'ਤੇ ਚੰਗੇ ਇरਾਦਿਆਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀਆਂ, ਪਰ ਉਹ ਕੰਟਰੋਲ ਤੋਂ ਬਾਹਰ ਹੋ ਜਾਂਦੀਆਂ:

• ਬਿਹੇਵਿਯਰ ਕਈ ਪੱਧਰਾਂ 'ਤੇ ਫੈਲ ਜਾਂਦਾ (“ਇਹ style ਕਿੱਥੋਂ ਆ ਰਿਹਾ ਹੈ?”)
• base class 'ਚ αλλαγές ਅਣਸੰਬੰਧਤ ਸਕ੍ਰੀਨਾਂ 'ਤੇ ਪ੍ਰਭਾਵ ਪਾਊਂਦੀਆਂ
• overrides ਇਕੱਠੇ ਹੋ ਜਾਂਦੀਆਂ ਅਤੇ “generic” base ਇੱਕ ਬੇਕਾਰ ਸੰਕਲਪ ਬਣ ਜਾਂਦਾ ਹੈ

ਆਧੁਨਿਕ composition ਟੂਲ: hooks

Hooks ਨੇ composition ਨੂੰ ਹੋਰ ਪ੍ਰਯੋਗਕ ਬਣਾਇਆ। ਇੱਕ custom hook ਜਿਵੇਂ useDebouncedValue ਜਾਂ usePermissions ਕਈ feature components ਨੂੰ logic share ਕਰਨ ਦਿੰਦੇ ਹਨ ਬਗੈਰ UI share ਕੀਤੇ। ਇਸਨੂੰ shared UI primitives (buttons, inputs, typography) ਅਤੇ feature components (CheckoutSummary, InviteUserForm) ਦੇ ਨਾਲ ਜੋੜੋ, ਅਤੇ ਤੁਹਾਨੂੰ ਏਸੇ ਤਰ੍ਹਾਂ ਦਾ reuse ਮਿਲਦਾ ਹੈ ਜੋ ਐਪ ਵਧਣ 'ਤੇ ਵੀ ਸਮਝਣਯੋਗ ਰਹਿੰਦਾ ਹੈ।

State Management: local state ਤੋਂ shared stores ਤੱਕ

React ਨੇ local component state ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਨੂੰ ਨੇਚੁਰਲ ਬਣਾਇਆ: ਇੱਕ ਫਾਰਮ ਫੀਲਡ ਦੀ value, ਇੱਕ dropdown ਖੁੱਲ੍ਹਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਇੱਕ loading spinner। ਇਹ ਚੰਗਾ ਕੰਮ ਕਰਦਾ—ਪਰ ਜਦ ਐਪ ਵੱਡਾ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਈ ਹਿੱਸਿਆਂ ਨੂੰ sync ਵਿੱਚ ਰਹਿਣਾ ਪੈਂਦਾ ਹੈ ਤਾਂ ਸਮੱਸਿਆ ਆਉਂਦੀ ਹੈ।

ਕਿਉਂ state ਸਾਂਝਾ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਹੈ

ਜਿਵੇਂ ਜਿਵੇਂ ਫੀਚਰ ਫੈਲਦੇ ਹਨ, 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, ਟੀਮ ਆਕਾਰ, ਅਤੇ ਬਦਲਾਅ ਦੀ ਤੀਵ੍ਰਤਾ 'ਤੇ ਵੱਧ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

Tooling ਅਤੇ ਵਰਕਫਲੋ React ਨੇ ਜਿਹੜੇ ਪ੍ਰਚਲਿਤ ਕੀਤੇ

React ਸਿਰਫ਼ UI ਲਿਖਣ ਦਾ ਤਰੀਕਾ ਨਹੀਂ ਦਿਤਾ—ਇਸ ਨੇ ਟੀਮਾਂ ਨੂੰ ਇਕ component-driven workflow ਵੱਲ ਧੱਕਿਆ ਜਿੱਥੇ ਕੋਡ, styling, ਅਤੇ ਵਿਹਾਰ ਛੋਟੇ, ਟੈਸਟੇਬਲ ਯੂਨਿਟਾਂ ਵਜੋਂ ਵਿਕਸਿਤ ਹੁੰਦੇ ਹਨ। ਇਹ ਬਦਲਾਅ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ ਕਿ ਫਰੰਟਐਂਡ ਪ੍ਰੋਜੈਕਟ ਕਿਵੇਂ ਬਣਾਏ, ਵੈਰੀਫਾਈ, ਦਸਤੀavez, ਅਤੇ ਸ਼ਿਪ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

Component-driven development ਇੱਕ ਰੋਜ਼ਾਨਾ ਵਰਕਫਲੋ ਵਜੋਂ

ਜਦ 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ਤਾ ਨੇ ਇੱਕ ਆਧੁਨਿਕ ਟੂਲਚੇਨ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕੀਤੀ ਜੋ ਬਹੁਤ ਟੀਮਾਂ ਹੁਣ ਮਿਆਰੀ ਮੰਨਦੀਆਂ ਹਨ:

• ਤੇਜ਼ local iteration ਲਈ bundlers ਅਤੇ dev servers (hot reload, code splitting)
• ਵੱਡੇ component ਕੋਡਬੇਸ ਨੂੰ consistent ਰੱਖਣ ਲਈ linting ਅਤੇ formatting
• component props ਅਤੇ state ਨੂੰ ਗਲਤ ਵਰਤੋਂ ਤੋਂ ਰੋਕਣ ਲਈ type checking (ਅਕਸਰ TypeScript)
• test runners ਅਤੇ component-focused testing utilities

ਯਦਿੱ ਤੁਸੀਂ ਉਹੋ ਹੀ ਟੂਲ ਚੁਣਦੇ ਨਹੀਂ ਵੀ, ਉਮੀਦ ਇਹ ਰਹਿੰਦੀ ਹੈ ਕਿ ਇੱਕ React ਐਪ ਵਿੱਚ guardrails ਹੋਣ ਜੋ UI regressions ਨੂੰ ਜਲਦੀ ਫੜ ਲੈਂਦੇ।

ਇਸ “workflow-first” ਸੋਚ ਦੇ ਨਵੇਂ ਵਾਧੇ ਵਜੋਂ, ਕੁਝ ਟੀਮਾਂ vibe-coding ਪਲੇਟਫਾਰਮਾਂ (ਉਦਾਹਰਨ: Koder.ai) ਵਰਤਦੀਆਂ ਹਨ ਜੋ React frontends (ਅਤੇ ਨਾਲ ਦਾ backend) ਨੂੰ chat-driven planning flow ਤੋਂ scaffold ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦੀਆਂ ਹਨ—ਜਦ ਤੁਸੀਂ component structure, state ownership, ਅਤੇ feature boundaries ਨੂੰ ਤੁਰੰਤ ਵੈਰੀਫਾਈ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਇਹ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦਾ ਹੈ।

“Component docs” ਅਤੇ isolated previews

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 UI ਲਾਇਬਰੇਰੀਆਂ ਲਈ ਚੰਗਾ ਹੈ

React components self-contained ਹੁੰਦੇ ਹਨ: ਉਹ structure, ਵਿਹਾਰ, ਅਤੇ styling ਨੂੰ ਇੱਕ ਸਥਿਰ ਇੰਟਰਫੇਸ ਦੇ ਪਿੱਛੇ ਬੰਨ੍ਹ ਸਕਦੇ ਹਨ। ਇਹ ਇੱਕ component library ਬਣਾਉਣ ਨੂੰ ਆਸਾਨ ਬਣਾਉਂਦਾ ਹੈ ਜੋ:

• Documented: ਹਰ component ਲਈ ਉਦਾਹਰਣ ਅਤੇ ਵਰਤੋਂ ਨੋਟ ਹੋ ਸਕਦੇ ਹਨ
• Versioned: ਬਦਲਾਅ incremental ਤਰੀਕੇ ਨਾਲ ਰਿਲੀਜ਼ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ
• Composable: ਛੋਟੇ ਟੁਕੜੇ ਵੱਡੇ ਪੈਟਰਨਾਂ ਵਿੱਚ ਮਿਲਕੇ ਕੰਮ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਣ: form fields + validation + layout)

ਜੇ ਤੁਸੀਂ ਨਵੇਂ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹੋ, ਇੱਕ ਸਧਾਰਣ ਚੈੱਕਲਿਸਟ ਇਸ ਗੱਲ ਨੂੰ ਰੋਕਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗੀ ਕਿ “ਕੰਪੋਨੈਂਟਾਂ ਦਾ ਇਕ ਢੇਰ” inconsistent ਗਰਮੀ ਵਿੱਚ ਨਹੀਂ ਬਦਲ ਜਾਏ: /blog/component-library-checklist.

ਇਕਰੂਪਤਾ ਜਿੱਤਦੀ ਹੈ: accessibility, theming, ਸਾਂਝਾ ਵਿਹਾਰ

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 ਸਰਹੱਦ ਤੁਹਾਨੂੰ ਦੋ ਲਾਭਦਾਇਕ ਪੱਧਰਾਂ ਤੇ ਟੈਸਟ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ:

• Unit tests: ਇੱਕ component ਦਿੱਤੇ props ਅਤੇ state ਲਈ ਠੀਕ ਤਰ੍ਹਾਂ render ਕਰਦਾ ਹੈ ਜਾਂ ਨਹੀਂ (edge cases ਸਮੇਤ) ਨੂੰ verify ਕਰੋ। ਤੁਸੀਂ components ਨੂੰ ਛੋਟੇ “UI functions” ਵਾਂਗ treat ਕਰ ਸਕਦੇ ਹੋ।
• Integration tests: ਇੱਕ ਛੋਟਾ tree (ਫਾਰਮ ਅਤੇ validation message, ਸੁਚੀ ਅਤੇ filters) ਰੈਂਡਰ ਕਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਯੂਜ਼ਰ ਵਿਹਾਰ ਸਹੀ UI ਬਦਲਾਅ ਲਿਆਉਂਦਾ ਹੈ।

ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ ਜਦ components ਦੀ clear ownership ਹੋਵੇ: ਇੱਕ ਜਗ੍ਹਾ ਜੋ state ਦੀ ਮਾਲਕੀ ਕਰਦੀ ਹੈ, ਅਤੇ children ਜੋ ਮੁੱਖ ਤਾਂ display ਕਰਦੇ ਅਤੇ event emit ਕਰਦੇ ਹਨ।

ਪ੍ਰਦਰਸ਼ਨ ਆਰਕੀਟੈਕਚਰ ਹੈ, ਨਾ ਕਿ ਨਿੱਕੇ-ਨਿੱਕੇ ਅੱਪਟੀਮਾਈਜੇਸ਼ਨ

React ਐਪ ਅਕਸਰ ਤੇਜ਼ ਮਹਿਸੂਸ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਟੀਮਾਂ performance ਨੂੰ structure ਵਿੱਚ ਹੀ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਸੋਚਦੀਆਂ ਹਨ:

• Code splitting: ਸਿਰਫ਼ ਉਹੀ ਲੋਡ ਕਰੋ ਜੋ ਕਿਸੇ ਰੂਟ ਜਾਂ ਫੀਚਰ ਨੂੰ ਚਾਹੀਦਾ ਹੈ, ਤਾਂ initial load ਛੋਟਾ ਰਹੇ
• Memoization: ਜਦ inputs ਬਦਲੇ ਨਹੀਂ ਤਾਂ unnecessary re-renders ਰੋਕੋ (ਇਸਦਾ ਸਹੀ ਤਰੀਕੇ ਨਾਲ, ਹਰ ਥਾਂ ਨਹੀਂ)
• Lazy loading: ਭਾਰੀ widgets (charts, editors) ਨੂੰ ਤਦ ਤੱਕ ਡੀਫ਼ਰ ਕਰੋ ਜਦ ਯੂਜ਼ਰ ਨੂੰ ਵਾਕਈ ਲੋੜ ਹੋਵੇ

ਇੱਕ ਵਰਤਣਯੋਗ ਨਿਯਮ: ਮਹਿੰਗੇ ਹਿੱਸਿਆਂ (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.