റിയാക്റ്റിന്റെ useEvent: സ്ഥിരതയുള്ള ഇവന്റ് ഹാൻഡ്ലറുകളുടെ ഭാവിയെക്കുറിച്ചൊരു ആഴത്തിലുള്ള പഠനം

നിരന്തരം വികസിച്ചുകൊണ്ടിരിക്കുന്ന റിയാക്റ്റ് ലോകത്ത്, ഡെവലപ്പർ അനുഭവം മെച്ചപ്പെടുത്തുന്നതിനും പൊതുവായ പ്രശ്നങ്ങൾ പരിഹരിക്കുന്നതിനും കോർ ടീം ശ്രമിച്ചുകൊണ്ടിരിക്കുന്നു. തുടക്കക്കാർ മുതൽ വിദഗ്ദ്ധർ വരെ നേരിടുന്ന ഒരു പ്രധാന വെല്ലുവിളി ഇവന്റ് ഹാൻഡ്ലറുകൾ കൈകാര്യം ചെയ്യുക, റഫറൻഷ്യൽ ഇന്റഗ്രിറ്റി നിലനിർത്തുക, useEffect, useCallback പോലുള്ള ഹുക്കുകളുടെ ഡിപെൻഡൻസി അറേകൾ എന്നിവയാണ്. വർഷങ്ങളായി ഡെവലപ്പർമാർ, പ്രകടനം ഒപ്റ്റിമൈസ് ചെയ്യുന്നതിനും സ്റ്റെയിൽ ക്ലോഷറുകൾ പോലുള്ള ബഗ്ഗുകൾ ഒഴിവാക്കുന്നതിനും ഇടയിൽ ഒരു സൂക്ഷ്മമായ ബാലൻസ് നിലനിർത്തിപ്പോരുന്നു.

ഈ സാഹചര്യത്തിലാണ് useEvent എന്ന നിർദ്ദിഷ്ട ഹുക്ക് വരുന്നത്, ഇത് റിയാക്റ്റ് കമ്മ്യൂണിറ്റിയിൽ വലിയ ആവേശം സൃഷ്ടിച്ചു. ഇത് ഇപ്പോഴും പരീക്ഷണാടിസ്ഥാനത്തിലാണെങ്കിലും, സ്ഥിരതയുള്ള ഒരു റിയാക്റ്റ് റിലീസിന്റെ ഭാഗമായിട്ടില്ലെങ്കിലും, ഇതിന്റെ ആശയം കൂടുതൽ ലളിതവും ശക്തവുമായ ഇവന്റ് കൈകാര്യം ചെയ്യലിന്റെ ഭാവിയെക്കുറിച്ചുള്ള ഒരു ആകർഷകമായ കാഴ്ച്ച നൽകുന്നു. ഈ സമഗ്രമായ ഗൈഡിൽ, useEvent പരിഹരിക്കാൻ ലക്ഷ്യമിടുന്ന പ്രശ്നങ്ങൾ, അത് എങ്ങനെ പ്രവർത്തിക്കുന്നു, അതിന്റെ പ്രായോഗിക ഉപയോഗങ്ങൾ, റിയാക്റ്റ് വികസനത്തിന്റെ ഭാവിയിൽ അതിനുള്ള സാധ്യതകൾ എന്നിവയെല്ലാം നമ്മൾ പരിശോധിക്കും.

അടിസ്ഥാന പ്രശ്നം: റഫറൻഷ്യൽ ഇന്റഗ്രിറ്റിയും ഡിപെൻഡൻസി ഡാൻസും

useEvent എന്തുകൊണ്ട് ഇത്ര പ്രാധാന്യമർഹിക്കുന്നു എന്ന് ശരിക്കും മനസ്സിലാക്കാൻ, അത് പരിഹരിക്കാൻ രൂപകൽപ്പന ചെയ്ത പ്രശ്നം എന്താണെന്ന് നമ്മൾ ആദ്യം മനസ്സിലാക്കണം. ഈ പ്രശ്നം ജാവാസ്ക്രിപ്റ്റ് ഫംഗ്ഷനുകളെ എങ്ങനെ കൈകാര്യം ചെയ്യുന്നു എന്നതിലും റിയാക്റ്റിന്റെ റെൻഡറിംഗ് രീതി എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നതിലും അധിഷ്ഠിതമാണ്.

എന്താണ് റഫറൻഷ്യൽ ഇന്റഗ്രിറ്റി?

ജാവാസ്ക്രിപ്റ്റിൽ, ഫംഗ്ഷനുകൾ ഒബ്ജക്റ്റുകളാണ്. ഒരു റിയാക്റ്റ് കമ്പോണന്റിനുള്ളിൽ നിങ്ങൾ ഒരു ഫംഗ്ഷൻ നിർവചിക്കുമ്പോൾ, ഓരോ റെൻഡറിലും ഒരു പുതിയ ഫംഗ്ഷൻ ഒബ്ജക്റ്റ് ഉണ്ടാകുന്നു. ഈ ലളിതമായ ഉദാഹരണം പരിഗണിക്കുക:

            
function MyComponent({ onLog }) {
  const handleClick = () => {
    console.log('Button clicked!');
  };

  // Every time MyComponent re-renders, a brand new `handleClick` function is created.
  return <button onClick={handleClick}>Click Me</button>;
}

            

              
                Copy
              
            
          

ഒരു സാധാരണ ബട്ടണിൽ ഇത് പ്രശ്നമില്ല. എന്നിരുന്നാലും, റിയാക്റ്റിൽ, ഈ സ്വഭാവത്തിന് കാര്യമായ പ്രത്യാഘാതങ്ങളുണ്ട്, പ്രത്യേകിച്ച് ഒപ്റ്റിമൈസേഷനുകളും എഫക്റ്റുകളും കൈകാര്യം ചെയ്യുമ്പോൾ. React.memo പോലുള്ള റിയാക്റ്റിന്റെ പെർഫോമൻസ് ഒപ്റ്റിമൈസേഷനുകളും, useEffect പോലുള്ള അതിന്റെ പ്രധാന ഹുക്കുകളും, വീണ്ടും റൺ ചെയ്യണോ അല്ലെങ്കിൽ റീ-റെൻഡർ ചെയ്യണോ എന്ന് തീരുമാനിക്കാൻ അവയുടെ ഡിപെൻഡൻസികളുടെ ഷാലോ കംപാരിസണുകളെ ആശ്രയിക്കുന്നു. ഓരോ റെൻഡറിലും ഒരു പുതിയ ഫംഗ്ഷൻ ഒബ്ജക്റ്റ് ഉണ്ടാക്കുന്നതുകൊണ്ട്, അതിന്റെ റഫറൻസ് (അല്ലെങ്കിൽ മെമ്മറി അഡ്രസ്സ്) എപ്പോഴും വ്യത്യസ്തമായിരിക്കും. റിയാക്റ്റിനെ സംബന്ധിച്ചിടത്തോളം, കോഡ് ഒന്നുതന്നെയാണെങ്കിൽ പോലും oldHandleClick !== newHandleClick ആണ്.

useCallback പരിഹാരവും അതിന്റെ സങ്കീർണ്ണതകളും

ഇത് കൈകാര്യം ചെയ്യാൻ റിയാക്റ്റ് ടീം ഒരു ടൂൾ നൽകിയിട്ടുണ്ട്: useCallback ഹുക്ക്. ഇത് ഒരു ഫംഗ്‌ഷനെ മെമ്മോയിസ് ചെയ്യുന്നു, അതായത് അതിന്റെ ഡിപെൻഡൻസികൾ മാറിയിട്ടില്ലെങ്കിൽ റീ-റെൻഡറുകളിലുടനീളം ഒരേ ഫംഗ്ഷൻ റഫറൻസ് തന്നെ തിരികെ നൽകുന്നു.

            
import React, { useState, useCallback } from 'react';

function MyComponent() {
  const [count, setCount] = useState(0);

  const handleClick = useCallback(() => {
    // This function's identity is now stable across re-renders
    console.log(`Current count is: ${count}`); 
  }, [count]); // ...but now it has a dependency

  useEffect(() => {
    // Some effect that depends on the click handler
    setupListener(handleClick);
    return () => removeListener(handleClick);
  }, [handleClick]); // This effect re-runs whenever handleClick changes

  return <button onClick={() => setCount(c => c + 1)}>Increment</button>;
}

            

              
                Copy
              
            
          

ഇവിടെ, count മാറുമ്പോൾ മാത്രമേ handleClick ഒരു പുതിയ ഫംഗ്ഷൻ ആവുകയുള്ളൂ. ഇത് ആദ്യത്തെ പ്രശ്നം പരിഹരിക്കുന്നു, പക്ഷേ ഒരു പുതിയ പ്രശ്നം ഉണ്ടാക്കുന്നു: ഡിപെൻഡൻസി അറേ ഡാൻസ്. ഇപ്പോൾ, handleClick ഉപയോഗിക്കുന്ന നമ്മുടെ useEffect ഹുക്ക്, handleClick-നെ ഒരു ഡിപെൻഡൻസിയായി ലിസ്റ്റ് ചെയ്യണം. handleClick, count-നെ ആശ്രയിക്കുന്നതുകൊണ്ട്, count മാറുമ്പോഴെല്ലാം എഫക്റ്റ് വീണ്ടും റൺ ചെയ്യും. ഇത് ചിലപ്പോൾ നിങ്ങൾക്ക് ആവശ്യമുള്ളതായിരിക്കാം, പക്ഷേ പലപ്പോഴും അങ്ങനെയല്ല. ഒരു ലിസണർ ഒരിക്കൽ മാത്രം സെറ്റപ്പ് ചെയ്യാനും, എന്നാൽ അത് എപ്പോഴും ക്ലിക്ക് ഹാൻഡ്ലറിന്റെ *ഏറ്റവും പുതിയ* പതിപ്പിനെ വിളിക്കാനും നിങ്ങൾ ആഗ്രഹിച്ചേക്കാം.

സ്റ്റെയിൽ ക്ലോഷറുകളുടെ അപകടം

നമ്മൾ കബളിപ്പിക്കാൻ ശ്രമിച്ചാലോ? ഫംഗ്ഷനെ സ്ഥിരമായി നിലനിർത്താൻ useCallback അറേയിൽ നിന്ന് ഒരു ഡിപെൻഡൻസി ഒഴിവാക്കുന്നത് സാധാരണവും എന്നാൽ അപകടകരവുമായ ഒരു രീതിയാണ്.

            
// ANTI-PATTERN: DO NOT DO THIS
const handleClick = useCallback(() => {
  console.log(`Current count is: ${count}`); 
}, []); // Omitted `count` from dependencies

            

              
                Copy
              
            
          

ഇപ്പോൾ, handleClick-ന് ഒരു സ്ഥിരമായ ഐഡന്റിറ്റിയുണ്ട്. useEffect ഒരിക്കൽ മാത്രം റൺ ചെയ്യും. പ്രശ്നം പരിഹരിച്ചോ? ഒരിക്കലുമില്ല. നമ്മൾ ഇപ്പോൾ ഒരു സ്റ്റെയിൽ ക്ലോഷർ ഉണ്ടാക്കിയിരിക്കുന്നു. useCallback-ലേക്ക് പാസ്സ് ചെയ്ത ഫംഗ്ഷൻ, അത് ഉണ്ടാക്കിയ സമയത്തെ സ്റ്റേറ്റിനെയും പ്രോപ്പുകളെയും "ക്ലോസ് ഓവർ" ചെയ്യുന്നു. നമ്മൾ ഒരു ശൂന്യമായ ഡിപെൻഡൻസി അറേ [] നൽകിയതുകൊണ്ട്, പ്രാരംഭ റെൻഡറിൽ ഫംഗ്ഷൻ ഒരിക്കൽ മാത്രമേ ഉണ്ടാകൂ. ആ സമയത്ത്, count 0 ആണ്. നിങ്ങൾ എത്ര തവണ ഇൻക്രിമെന്റ് ബട്ടൺ ക്ലിക്ക് ചെയ്താലും, handleClick എപ്പോഴും "Current count is: 0" എന്ന് ലോഗ് ചെയ്യും. അത് count സ്റ്റേറ്റിന്റെ ഒരു പഴയ മൂല്യത്തിൽ പിടിച്ചുനിൽക്കുകയാണ്.

ഇതാണ് അടിസ്ഥാനപരമായ ധർമ്മസങ്കടം: ഒന്നുകിൽ നിരന്തരം മാറിക്കൊണ്ടിരിക്കുന്ന ഒരു ഫംഗ്ഷൻ റഫറൻസ്, അത് അനാവശ്യമായ റീ-റെൻഡറുകൾക്കും എഫക്റ്റ് റീ-റണ്ണുകൾക്കും കാരണമാകുന്നു, അല്ലെങ്കിൽ നിങ്ങൾ സൂക്ഷ്മവും ഡീബഗ് ചെയ്യാൻ പ്രയാസമുള്ളതുമായ സ്റ്റെയിൽ ക്ലോഷർ ബഗ്ഗുകൾ ഉണ്ടാക്കാൻ സാധ്യതയുണ്ട്.

useEvent പരിചയപ്പെടുത്തുന്നു: രണ്ട് ലോകങ്ങളിലെയും മികച്ചത്

നിർദ്ദിഷ്ട useEvent ഹുക്ക് ഈ പ്രതിസന്ധി തകർക്കാൻ രൂപകൽപ്പന ചെയ്തിട്ടുള്ളതാണ്. അതിന്റെ പ്രധാന വാഗ്ദാനം ലളിതവും എന്നാൽ വിപ്ലവകരവുമാണ്:

സ്ഥിരമായ ഐഡന്റിറ്റിയുള്ള ഒരു ഫംഗ്ഷൻ നൽകുക, എന്നാൽ അതിന്റെ പ്രവർത്തനം എപ്പോഴും ഏറ്റവും പുതിയതും അപ്‌ഡേറ്റ് ചെയ്തതുമായ സ്റ്റേറ്റും പ്രോപ്പുകളും ഉപയോഗിക്കുന്നു.

അതിന്റെ നിർദ്ദിഷ്ട സിന്റാക്സ് നോക്കാം:

            
import { useEvent } from 'react'; // Hypothetical import

function MyComponent() {
  const [count, setCount] = useState(0);

  const handleClick = useEvent(() => {
    // No dependency array needed!
    // This code will always see the latest `count` value.
    console.log(`Current count is: ${count}`);
  });

  useEffect(() => {
    // setupListener is called only once on mount.
    // handleClick has a stable identity and is safe to omit from the dependency array.
    setupListener(handleClick);
    return () => removeListener(handleClick);
  }, []); // No need to include handleClick here!

  return <button onClick={() => setCount(c => c + 1)}>Increment</button>;
}

            

              
                Copy
              
            
          

ഈ രണ്ട് പ്രധാന മാറ്റങ്ങൾ ശ്രദ്ധിക്കുക:

1. useEvent ഒരു ഫംഗ്ഷൻ എടുക്കുന്നു, പക്ഷേ ഇതിന് ഡിപെൻഡൻസി അറേ ഇല്ല.
2. useEvent തിരികെ നൽകുന്ന handleClick ഫംഗ്ഷൻ വളരെ സ്ഥിരതയുള്ളതായതുകൊണ്ട്, റിയാക്റ്റ് ഡോക്സ് useEffect ഡിപെൻഡൻസി അറേയിൽ നിന്ന് ഇത് ഒഴിവാക്കാൻ ഔദ്യോഗികമായി അനുവദിക്കും (ലിന്റ് റൂൾ ഇതിനെ അവഗണിക്കാൻ പഠിപ്പിക്കും).

ഇത് രണ്ട് പ്രശ്നങ്ങളും ലളിതമായി പരിഹരിക്കുന്നു. ഫംഗ്ഷന്റെ ഐഡന്റിറ്റി സ്ഥിരതയുള്ളതായതിനാൽ, useEffect അനാവശ്യമായി വീണ്ടും പ്രവർത്തിക്കുന്നത് തടയുന്നു. അതേസമയം, അതിന്റെ ആന്തരിക ലോജിക് എപ്പോഴും അപ്‌ഡേറ്റ് ചെയ്യപ്പെടുന്നതിനാൽ, അത് ഒരിക്കലും സ്റ്റെയിൽ ക്ലോഷറുകൾക്ക് വിധേയമാകുന്നില്ല. നിങ്ങൾക്ക് സ്ഥിരതയുള്ള റഫറൻസിന്റെ പ്രകടന നേട്ടവും എപ്പോഴും ഏറ്റവും പുതിയ ഡാറ്റയുടെ കൃത്യതയും ലഭിക്കുന്നു.

പ്രവർത്തനത്തിൽ `useEvent`: പ്രായോഗിക ഉപയോഗങ്ങൾ

useEvent-ന്റെ പ്രത്യാഘാതങ്ങൾ വളരെ വലുതാണ്. കോഡ് ലളിതമാക്കുകയും വിശ്വാസ്യത മെച്ചപ്പെടുത്തുകയും ചെയ്യുന്ന ചില സാധാരണ സാഹചര്യങ്ങൾ നമുക്ക് നോക്കാം.

1. `useEffect`, ഇവന്റ് ലിസണറുകൾ എന്നിവ ലളിതമാക്കുന്നു

ഇതാണ് ഏറ്റവും നല്ല ഉദാഹരണം. വിൻഡോ റീസൈസിംഗ്, കീബോർഡ് ഷോർട്ട്‌കട്ടുകൾ, അല്ലെങ്കിൽ വെബ്‌സോക്കറ്റ് സന്ദേശങ്ങൾ പോലുള്ള ഗ്ലോബൽ ഇവന്റ് ലിസണറുകൾ സജ്ജീകരിക്കുന്നത് സാധാരണയായി ഒരിക്കൽ മാത്രം ചെയ്യേണ്ട ഒരു സാധാരണ ജോലിയാണ്.

`useEvent`-ന് മുൻപ്:

            
function ChatRoom({ roomId }) {
  const [messages, setMessages] = useState([]);

  const onMessage = useCallback((newMessage) => {
    // We need `messages` to add the new message
    setMessages([...messages, newMessage]);
  }, [messages]); // Dependency on `messages` makes `onMessage` unstable

  useEffect(() => {
    const socket = createSocket(roomId);
    socket.on('message', onMessage);
    return () => socket.off('message', onMessage);
  }, [roomId, onMessage]); // Effect re-subscribes every time `messages` changes
}

            

              
                Copy
              
            
          

ഈ കോഡിൽ, ഓരോ തവണയും ഒരു പുതിയ സന്ദേശം വരുമ്പോഴും messages സ്റ്റേറ്റ് അപ്‌ഡേറ്റ് ചെയ്യുമ്പോഴും ഒരു പുതിയ onMessage ഫംഗ്ഷൻ ഉണ്ടാകുന്നു. ഇത് useEffect പഴയ സോക്കറ്റ് സബ്സ്ക്രിപ്ഷൻ നീക്കം ചെയ്യാനും പുതിയൊരെണ്ണം ഉണ്ടാക്കാനും കാരണമാകുന്നു. ഇത് കാര്യക്ഷമമല്ലാത്തതും സന്ദേശങ്ങൾ നഷ്ടപ്പെടുന്നത് പോലുള്ള ബഗ്ഗുകളിലേക്ക് നയിച്ചേക്കാവുന്നതുമാണ്.

`useEvent`-ന് ശേഷം:

            
function ChatRoom({ roomId }) {
  const [messages, setMessages] = useState([]);

  const onMessage = useEvent((newMessage) => {
    // `useEvent` ensures this function always has the latest `messages` state
    setMessages([...messages, newMessage]);
  });

  useEffect(() => {
    const socket = createSocket(roomId);
    socket.on('message', onMessage);
    return () => socket.off('message', onMessage);
  }, [roomId]); // `onMessage` is stable, so we only re-subscribe if `roomId` changes
}

            

              
                Copy
              
            
          

കോഡ് ഇപ്പോൾ കൂടുതൽ ലളിതവും, മനസ്സിലാക്കാൻ എളുപ്പമുള്ളതും, കൂടുതൽ ശരിയുമാണ്. സോക്കറ്റ് കണക്ഷൻ roomId-യെ മാത്രം അടിസ്ഥാനമാക്കി കൈകാര്യം ചെയ്യപ്പെടുന്നു, അത് അങ്ങനെത്തന്നെയാണ് വേണ്ടതും. അതേസമയം സന്ദേശങ്ങൾക്കുള്ള ഇവന്റ് ഹാൻഡ്ലർ ഏറ്റവും പുതിയ സ്റ്റേറ്റ് സുതാര്യമായി കൈകാര്യം ചെയ്യുന്നു.

2. കസ്റ്റം ഹുക്കുകൾ ഒപ്റ്റിമൈസ് ചെയ്യുന്നു

കസ്റ്റം ഹുക്കുകൾ പലപ്പോഴും കോൾബാക്ക് ഫംഗ്ഷനുകൾ ആർഗ്യുമെന്റുകളായി സ്വീകരിക്കുന്നു. ഉപയോക്താവ് ഒരു സ്ഥിരതയുള്ള ഫംഗ്ഷൻ പാസ് ചെയ്യുന്നുണ്ടോ എന്നതിൽ കസ്റ്റം ഹുക്കിന്റെ നിർമ്മാതാവിന് നിയന്ത്രണമില്ല, ഇത് പ്രകടനപരമായ കെണികളിലേക്ക് നയിച്ചേക്കാം.

`useEvent`-ന് മുൻപ്:

ഒരു API പോൾ ചെയ്യുന്നതിനുള്ള ഒരു കസ്റ്റം ഹുക്ക്:

            
function usePolling(url, onData) {
  useEffect(() => {
    const intervalId = setInterval(async () => {
      const data = await fetch(url).then(res => res.json());
      onData(data);
    }, 5000);

    return () => clearInterval(intervalId);
  }, [url, onData]); // Unstable `onData` will restart the interval
}

// Component using the hook
function StockTicker() {
  const [price, setPrice] = useState(0);

  // This function is re-created on every render, causing the polling to restart
  const handleNewPrice = (data) => {
    setPrice(data.price);
  };

  usePolling('/api/stock', handleNewPrice);

  return <div>Price: {price}</div>
}

            

              
                Copy
              
            
          

ഇത് പരിഹരിക്കാൻ, usePolling ഉപയോഗിക്കുന്നയാൾ handleNewPrice-നെ useCallback-ൽ പൊതിയേണ്ടതുണ്ടെന്ന് ഓർക്കണം. ഇത് ഹുക്കിന്റെ API-യെ ഉപയോഗിക്കാൻ ബുദ്ധിമുട്ടുള്ളതാക്കുന്നു.

`useEvent`-ന് ശേഷം:

useEvent ഉപയോഗിച്ച് കസ്റ്റം ഹുക്കിനെ ആന്തരികമായി ശക്തമാക്കാം.

            
function usePolling(url, onData) {
  // Wrap the user's callback in `useEvent` inside the hook
  const stableOnData = useEvent(onData);

  useEffect(() => {
    const intervalId = setInterval(async () => {
      const data = await fetch(url).then(res => res.json());
      stableOnData(data); // Call the stable wrapper
    }, 5000);

    return () => clearInterval(intervalId);
  }, [url]); // Now the effect only depends on `url`
}

// Component using the hook can be much simpler
function StockTicker() {
  const [price, setPrice] = useState(0);

  // No need for useCallback here!
  usePolling('/api/stock', (data) => {
    setPrice(data.price);
  });

  return <div>Price: {price}</div>
}

            

              
                Copy
              
            
          

ഉത്തരവാദിത്തം ഹുക്കിന്റെ രചയിതാവിലേക്ക് മാറുന്നു, ഇത് ഹുക്കിന്റെ എല്ലാ ഉപഭോക്താക്കൾക്കും വൃത്തിയുള്ളതും സുരക്ഷിതവുമായ ഒരു API നൽകുന്നു.

3. മെമ്മോയിസ് ചെയ്ത കമ്പോണന്റുകൾക്കുള്ള സ്ഥിരതയുള്ള കോൾബാക്കുകൾ

React.memo-യിൽ പൊതിഞ്ഞ കമ്പോണന്റുകളിലേക്ക് കോൾബാക്കുകൾ പ്രോപ്പുകളായി കൈമാറുമ്പോൾ, അനാവശ്യമായ റീ-റെൻഡറുകൾ തടയാൻ നിങ്ങൾ useCallback ഉപയോഗിക്കണം. useEvent ഉദ്ദേശ്യം പ്രഖ്യാപിക്കാൻ കൂടുതൽ നേരിട്ടുള്ള ഒരു മാർഗ്ഗം നൽകുന്നു.

            
const MemoizedButton = React.memo(({ onClick, children }) => {
  console.log('Rendering button:', children);
  return <button onClick={onClick}>{children}</button>;
});

function Dashboard() {
  const [user, setUser] = useState('Alice');

  // With `useEvent`, this function is declared as a stable event handler
  const handleSave = useEvent(() => {
    saveUserDetails(user);
  });

  return (
    <div>
      <input value={user} onChange={e => setUser(e.target.value)} />
      {/* `handleSave` has a stable identity, so MemoizedButton won't re-render when `user` changes */}
      <MemoizedButton onClick={handleSave}>Save</MemoizedButton>
    </div>
  );
}

            

              
                Copy
              
            
          

ഈ ഉദാഹരണത്തിൽ, നിങ്ങൾ ഇൻപുട്ട് ബോക്സിൽ ടൈപ്പ് ചെയ്യുമ്പോൾ, user സ്റ്റേറ്റ് മാറുന്നു, കൂടാതെ Dashboard കമ്പോണന്റ് റീ-റെൻഡർ ചെയ്യുന്നു. സ്ഥിരതയുള്ള ഒരു handleSave ഫംഗ്ഷൻ ഇല്ലാതെ, ഓരോ കീസ്ട്രോക്കിലും MemoizedButton റീ-റെൻഡർ ചെയ്യും. useEvent ഉപയോഗിക്കുന്നതിലൂടെ, handleSave ഒരു ഇവന്റ് ഹാൻഡ്ലർ ആണെന്നും അതിന്റെ ഐഡന്റിറ്റി കമ്പോണന്റിന്റെ റെൻഡർ സൈക്കിളുമായി ബന്ധിപ്പിക്കരുതെന്നും നമ്മൾ സൂചിപ്പിക്കുന്നു. ഇത് സ്ഥിരമായി തുടരുന്നു, ബട്ടൺ റീ-റെൻഡർ ചെയ്യുന്നത് തടയുന്നു, പക്ഷേ ക്ലിക്ക് ചെയ്യുമ്പോൾ, അത് എപ്പോഴും saveUserDetails-നെ user-ന്റെ ഏറ്റവും പുതിയ മൂല്യം ഉപയോഗിച്ച് വിളിക്കും.

അണിയറയിൽ: `useEvent` എങ്ങനെ പ്രവർത്തിക്കുന്നു?

അന്തിമമായ നിർവ്വഹണം റിയാക്റ്റിന്റെ ആന്തരിക ഘടനയിൽ വളരെ ഒപ്റ്റിമൈസ് ചെയ്യപ്പെടുമെങ്കിലും, ഒരു ലളിതമായ പോളിഫിൽ ഉണ്ടാക്കി നമുക്ക് അതിന്റെ പ്രധാന ആശയം മനസ്സിലാക്കാം. സ്ഥിരതയുള്ള ഒരു ഫംഗ്ഷൻ റഫറൻസും, ഏറ്റവും പുതിയ നിർവ്വഹണം സൂക്ഷിക്കുന്ന ഒരു മ്യൂട്ടബിൾ റെഫും സംയോജിപ്പിക്കുന്നതിലാണ് ഇതിന്റെ മാന്ത്രികത.

ഇവിടെ ഒരു ആശയപരമായ നിർവ്വഹണം നൽകുന്നു:

            
import { useRef, useLayoutEffect, useCallback } from 'react';

export function useEvent(handler) {
  // Create a ref to hold the latest version of the handler function.
  const handlerRef = useRef(null);

  // `useLayoutEffect` runs synchronously after DOM mutations but before the browser paints.
  // This ensures the ref is updated before any event can be triggered by the user.
  useLayoutEffect(() => {
    handlerRef.current = handler;
  });

  // Return a stable, memoized function that never changes.
  // This is the function that will be passed as a prop or used in an effect.
  return useCallback((...args) => {
    // When called, it invokes the *current* handler from the ref.
    const fn = handlerRef.current;
    return fn(...args);
  }, []);
}

            

              
                Copy
              
            
          

നമുക്ക് ഇതിനെ വിഭജിച്ചു നോക്കാം:

1. `useRef`: നമ്മൾ ഒരു handlerRef ഉണ്ടാക്കുന്നു. ഒരു റെഫ്, റെൻഡറുകളിലുടനീളം നിലനിൽക്കുന്ന ഒരു മ്യൂട്ടബിൾ ഒബ്ജക്റ്റാണ്. അതിന്റെ .current പ്രോപ്പർട്ടി ഒരു റീ-റെൻഡറിന് കാരണമാകാതെ മാറ്റാൻ കഴിയും.
2. `useLayoutEffect`: ഓരോ റെൻഡറിലും, ഈ എഫക്റ്റ് പ്രവർത്തിക്കുകയും handlerRef.current-നെ നമ്മൾക്ക് ലഭിച്ച പുതിയ handler ഫംഗ്ഷനിലേക്ക് അപ്ഡേറ്റ് ചെയ്യുകയും ചെയ്യുന്നു. ബ്രൗസറിന് പെയിന്റ് ചെയ്യാൻ അവസരം ലഭിക്കുന്നതിന് മുൻപ് ഈ അപ്ഡേറ്റ് സിൻക്രണസ് ആയി നടക്കുന്നുവെന്ന് ഉറപ്പാക്കാൻ നമ്മൾ useEffect-ന് പകരം useLayoutEffect ഉപയോഗിക്കുന്നു. ഇത് ഒരു ഇവന്റ് ഫയർ ചെയ്യുകയും മുൻപത്തെ റെൻഡറിലെ പഴയ ഹാൻഡ്ലറിനെ വിളിക്കുകയും ചെയ്യാൻ സാധ്യതയുള്ള ഒരു ചെറിയ ഇടവേള ഒഴിവാക്കുന്നു.
3. `useCallback` with `[]`: ഇതാണ് സ്ഥിരതയുടെ താക്കോൽ. നമ്മൾ ഒരു റാപ്പർ ഫംഗ്ഷൻ ഉണ്ടാക്കി അതിനെ ഒരു ശൂന്യമായ ഡിപെൻഡൻസി അറേ ഉപയോഗിച്ച് മെമ്മോയിസ് ചെയ്യുന്നു. ഇതിനർത്ഥം, എല്ലാ റെൻഡറുകളിലുടനീളം ഈ റാപ്പറിനായി റിയാക്റ്റ് *എല്ലായ്പ്പോഴും* ഒരേ ഫംഗ്ഷൻ ഒബ്ജക്റ്റ് തന്നെ തിരികെ നൽകും. ഇതാണ് നമ്മുടെ ഹുക്ക് ഉപയോഗിക്കുന്നവർക്ക് ലഭിക്കുന്ന സ്ഥിരതയുള്ള ഫംഗ്ഷൻ.
4. സ്ഥിരതയുള്ള റാപ്പർ: ഈ സ്ഥിരതയുള്ള ഫംഗ്ഷന്റെ ഒരേയൊരു ജോലി, handlerRef.current-ൽ നിന്ന് ഏറ്റവും പുതിയ ഹാൻഡ്ലർ വായിച്ച് അത് എക്സിക്യൂട്ട് ചെയ്യുക, ഒപ്പം ഏതെങ്കിലും ആർഗ്യുമെന്റുകൾ കൈമാറുക എന്നതാണ്.

ഈ സമർത്ഥമായ സംയോജനം നമുക്ക് പുറമേ സ്ഥിരതയുള്ളതും (റാപ്പർ) എന്നാൽ ഉള്ളിൽ എപ്പോഴും ഡൈനാമിക്കുമായ (റെഫിൽ നിന്ന് വായിക്കുന്നതിലൂടെ) ഒരു ഫംഗ്ഷൻ നൽകുന്നു, ഇത് നമ്മുടെ ധർമ്മസങ്കടം പൂർണ്ണമായി പരിഹരിക്കുന്നു.

`useEvent`-ന്റെ നിലയും ഭാവിയും

2023 അവസാനത്തിലും 2024 ആദ്യത്തിലും, useEvent റിയാക്റ്റിന്റെ സ്ഥിരതയുള്ള ഒരു പതിപ്പിൽ റിലീസ് ചെയ്തിട്ടില്ല. ഇത് ഒരു ഔദ്യോഗിക RFC (Request for Comments)-ൽ അവതരിപ്പിക്കുകയും റിയാക്റ്റിന്റെ എക്സ്പെരിമെന്റൽ റിലീസ് ചാനലിൽ കുറച്ചുകാലം ലഭ്യമാകുകയും ചെയ്തിരുന്നു. എന്നിരുന്നാലും, ഈ നിർദ്ദേശം പിന്നീട് RFC-കളുടെ ശേഖരത്തിൽ നിന്ന് പിൻവലിക്കുകയും ചർച്ചകൾ കുറയുകയും ചെയ്തു.

എന്തുകൊണ്ട് ഈ താൽക്കാലിക വിരാമം? ഇതിന് നിരവധി സാധ്യതകളുണ്ട്:

• അപൂർവ്വ സാഹചര്യങ്ങളും API ഡിസൈനും: റിയാക്റ്റിലേക്ക് ഒരു പുതിയ പ്രിമിറ്റീവ് ഹുക്ക് അവതരിപ്പിക്കുന്നത് വലിയൊരു തീരുമാനമാണ്. ടീം ഒരുപക്ഷേ സങ്കീർണ്ണമായ ചില അപൂർവ്വ സാഹചര്യങ്ങൾ കണ്ടെത്തിയിരിക്കാം അല്ലെങ്കിൽ കമ്മ്യൂണിറ്റിയിൽ നിന്ന് ലഭിച്ച ഫീഡ്ബാക്ക് API-യെക്കുറിച്ചോ അതിന്റെ അടിസ്ഥാന സ്വഭാവത്തെക്കുറിച്ചോ പുനർവിചിന്തനം ചെയ്യാൻ പ്രേരിപ്പിച്ചിരിക്കാം.
• റിയാക്റ്റ് കംപൈലറിന്റെ വരവ്: റിയാക്റ്റ് ടീമിന്റെ ഒരു പ്രധാന പ്രോജക്റ്റാണ് "റിയാക്റ്റ് കംപൈലർ" (മുൻപ് "ഫോർഗെറ്റ്" എന്ന കോഡ് നാമത്തിൽ അറിയപ്പെട്ടിരുന്നു). ഈ കംപൈലർ കമ്പോണന്റുകളെയും ഹുക്കുകളെയും ഓട്ടോമാറ്റിക്കായി മെമ്മോയിസ് ചെയ്യാൻ ലക്ഷ്യമിടുന്നു, ഇത് ഡെവലപ്പർമാർക്ക് useCallback, useMemo, React.memo എന്നിവ സ്വമേധയാ ഉപയോഗിക്കേണ്ടതിന്റെ ആവശ്യകത ഇല്ലാതാക്കുന്നു. ഒരു ഫംഗ്ഷന്റെ ഐഡന്റിറ്റി എപ്പോഴാണ് സംരക്ഷിക്കേണ്ടതെന്ന് മനസ്സിലാക്കാൻ കംപൈലറിന് കഴിയുമെങ്കിൽ, അത് useEvent പരിഹരിക്കാൻ രൂപകൽപ്പന ചെയ്ത പ്രശ്നം ഒരുപക്ഷേ കൂടുതൽ അടിസ്ഥാനപരവും ഓട്ടോമേറ്റഡുമായ തലത്തിൽ പരിഹരിച്ചേക്കാം.
• ബദൽ പരിഹാരങ്ങൾ: ഒരു പുതിയ ഹുക്ക് ആശയം അവതരിപ്പിക്കാതെ തന്നെ അതേ പ്രശ്നങ്ങൾ പരിഹരിക്കാൻ കോർ ടീം ഒരുപക്ഷേ മറ്റ്, ഒരുപക്ഷേ ലളിതമായ, API-കൾ പരീക്ഷിക്കുന്നുണ്ടാവാം.

ഒരു ഔദ്യോഗിക ദിശാബോധത്തിനായി നമ്മൾ കാത്തിരിക്കുമ്പോൾ, useEvent-ന് പിന്നിലെ *ആശയം* വളരെ വിലപ്പെട്ടതാണ്. ഇത് ഒരു ഇവന്റിന്റെ ഐഡന്റിറ്റിയെ അതിന്റെ നിർവ്വഹണത്തിൽ നിന്ന് വേർതിരിക്കുന്നതിനുള്ള ഒരു വ്യക്തമായ മാനസിക മാതൃക നൽകുന്നു. ഒരു ഔദ്യോഗിക ഹുക്ക് ഇല്ലെങ്കിൽ പോലും, ഡെവലപ്പർമാർക്ക് മുകളിൽ പറഞ്ഞ പോളിഫിൽ പാറ്റേൺ (use-event-listener പോലുള്ള കമ്മ്യൂണിറ്റി ലൈബ്രറികളിൽ ഇത് കാണാം) ഉപയോഗിച്ച് സമാനമായ ഫലങ്ങൾ നേടാൻ കഴിയും, ഔദ്യോഗിക അംഗീകാരവും ലിന്റർ പിന്തുണയും ഇല്ലെങ്കിൽ പോലും.

ഉപസംഹാരം: ഇവന്റുകളെക്കുറിച്ച് ചിന്തിക്കാനുള്ള ഒരു പുതിയ രീതി

useEvent-ന്റെ നിർദ്ദേശം റിയാക്റ്റ് ഹുക്കുകളുടെ പരിണാമത്തിലെ ഒരു സുപ്രധാന നിമിഷമായിരുന്നു. ഫംഗ്ഷൻ ഐഡന്റിറ്റി, useCallback, useEffect ഡിപെൻഡൻസി അറേകൾ എന്നിവ തമ്മിലുള്ള പരസ്പരപ്രവർത്തനം മൂലമുണ്ടാകുന്ന അന്തർലീനമായ സംഘർഷവും മാനസിക ഭാരവും റിയാക്റ്റ് ടീം ഔദ്യോഗികമായി അംഗീകരിക്കുന്ന ആദ്യത്തെ സന്ദർഭമായിരുന്നു ഇത്.

useEvent റിയാക്റ്റിന്റെ സ്ഥിരതയുള്ള API-യുടെ ഭാഗമാകുമോ അതോ അതിന്റെ സത്ത വരാനിരിക്കുന്ന റിയാക്റ്റ് കംപൈലറിലേക്ക് ആഗിരണം ചെയ്യപ്പെടുമോ എന്നതിലുപരി, അത് ഉയർത്തിക്കാട്ടുന്ന പ്രശ്നം യഥാർത്ഥവും പ്രധാനപ്പെട്ടതുമാണ്. നമ്മുടെ ഫംഗ്ഷനുകളുടെ സ്വഭാവത്തെക്കുറിച്ച് കൂടുതൽ വ്യക്തമായി ചിന്തിക്കാൻ ഇത് നമ്മെ പ്രോത്സാഹിപ്പിക്കുന്നു:

• ഇതൊരു ഇവന്റ് ഹാൻഡ്ലർ ആണോ, അതിന്റെ ഐഡന്റിറ്റി സ്ഥിരതയുള്ളതായിരിക്കണോ?
• അതോ, ഫംഗ്ഷന്റെ ലോജിക് മാറുമ്പോൾ എഫക്റ്റ് വീണ്ടും സിൻക്രൊണൈസ് ചെയ്യാൻ കാരണമാകേണ്ട ഒരു ഫംഗ്ഷൻ ആണോ ഇത്?

ഈ രണ്ട് കേസുകളും തമ്മിൽ വ്യക്തമായി വേർതിരിച്ചറിയാൻ ഒരു ഉപകരണം—അല്ലെങ്കിൽ കുറഞ്ഞത് ഒരു ആശയം—നൽകുന്നതിലൂടെ, റിയാക്റ്റിന് കൂടുതൽ ഡിക്ലറേറ്റീവും, പിശകുകൾ കുറഞ്ഞതും, പ്രവർത്തിക്കാൻ കൂടുതൽ ആസ്വാദ്യകരവുമാകാൻ കഴിയും. അതിന്റെ അന്തിമ രൂപത്തിനായി നമ്മൾ കാത്തിരിക്കുമ്പോൾ, useEvent-നെക്കുറിച്ചുള്ള ഈ ആഴത്തിലുള്ള പഠനം സങ്കീർണ്ണമായ ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നതിലെ വെല്ലുവിളികളെക്കുറിച്ചും റിയാക്റ്റ് പോലുള്ള ഒരു ഫ്രെയിംവർക്കിനെ ശക്തവും ലളിതവുമാക്കുന്നതിന് പിന്നിലെ മികച്ച എഞ്ചിനീയറിംഗിനെക്കുറിച്ചും വിലയേറിയ ഉൾക്കാഴ്ച നൽകുന്നു.