ரியாக்ட் காம்போனென்ட் கட்டமைப்பு: மரபுரிமையை (Inheritance) விட கலவை (Composition) ஏன் சிறந்தது

மென்பொருள் மேம்பாட்டு உலகில், கட்டமைப்பு மிக முக்கியமானது. நாம் நமது குறியீட்டை கட்டமைக்கும் விதம் அதன் அளவிடுதல், பராமரிப்பு மற்றும் மறுபயன்பாடு ஆகியவற்றை தீர்மானிக்கிறது. ரியாக்டில் பணிபுரியும் டெவலப்பர்களுக்கு, காம்போனென்டுகளுக்கு இடையில் லாஜிக் மற்றும் UI-ஐ எவ்வாறு பகிர்வது என்பது மிக அடிப்படையான கட்டமைப்பு முடிவுகளில் ஒன்றாகும். இது பொருள்-சார் நிரலாக்கத்தின் (object-oriented programming) ஒரு பழமையான விவாதத்திற்கு நம்மை அழைத்துச் செல்கிறது, இது ரியாக்டின் காம்போனென்ட்-அடிப்படையிலான உலகிற்காக மறுவடிவமைப்பு செய்யப்பட்டுள்ளது: கலவை (Composition) vs. மரபுரிமை (Inheritance).

நீங்கள் ஜாவா அல்லது சி++ போன்ற கிளாசிக்கல் பொருள்-சார் மொழிகளின் பின்னணியில் இருந்து வந்தால், மரபுரிமை ஒரு இயல்பான முதல் தேர்வாகத் தோன்றலாம். இது 'is-a' உறவுகளை உருவாக்குவதற்கான ஒரு சக்திவாய்ந்த கருத்து. இருப்பினும், அதிகாரப்பூர்வ ரியாக்ட் ஆவணங்கள் ஒரு தெளிவான மற்றும் வலுவான பரிந்துரையை வழங்குகிறது: "பேஸ்புக்கில், நாங்கள் ஆயிரக்கணக்கான காம்போனென்டுகளில் ரியாக்டைப் பயன்படுத்துகிறோம், மேலும் காம்போனென்ட் மரபுரிமை படிநிலைகளை உருவாக்க நாங்கள் பரிந்துரைக்கும் எந்தவொரு பயன்பாட்டு நிகழ்வுகளையும் நாங்கள் காணவில்லை."

இந்த பதிவு இந்த கட்டமைப்புத் தேர்வின் விரிவான ஆய்வை வழங்கும். ரியாக்ட் சூழலில் மரபுரிமை மற்றும் கலவை என்றால் என்ன என்பதை நாம் விரிவாக ஆராய்வோம், கலவை ஏன் மரபு சார்ந்த மற்றும் உயர்ந்த அணுகுமுறை என்பதை நிரூபிப்போம், மேலும் உயர்-நிலை காம்போனென்டுகள் (Higher-Order Components) முதல் நவீன ஹூக்ஸ் (Hooks) வரை உள்ள சக்திவாய்ந்த பேட்டர்ன்களை ஆராய்வோம் - இது உலகளாவிய பார்வையாளர்களுக்காக வலுவான மற்றும் நெகிழ்வான பயன்பாடுகளை உருவாக்குவதில் டெவலப்பரின் சிறந்த நண்பனாக கலவையை மாற்றுகிறது.

பழைய முறையைப் புரிந்துகொள்ளுதல்: மரபுரிமை என்றால் என்ன?

மரபுரிமை என்பது பொருள்-சார் நிரலாக்கத்தின் (OOP) ஒரு முக்கிய தூணாகும். இது ஒரு புதிய கிளாஸ் (துணை கிளாஸ் அல்லது சைல்டு) ஏற்கனவே உள்ள கிளாஸின் (சூப்பர் கிளாஸ் அல்லது பேரண்ட்) பண்புகள் மற்றும் மெத்தடுகளைப் பெற அனுமதிக்கிறது. இது ஒரு இறுக்கமாகப் பிணைக்கப்பட்ட 'is-a' உறவை உருவாக்குகிறது. உதாரணமாக, ஒரு GoldenRetriever is a Dog, அது ஒரு Animal ஆகும்.

ரியாக்ட் அல்லாத சூழலில் மரபுரிமை

இந்த கருத்தை வலுப்படுத்த ஒரு எளிய ஜாவாஸ்கிரிப்ட் கிளாஸ் உதாரணத்தைப் பார்ப்போம்:

class Animal {
  constructor(name) {
    this.name = name;
  }

  speak() {
    console.log(`${this.name} makes a noise.`);
  }
}

class Dog extends Animal {
  constructor(name, breed) {
    super(name); // Calls the parent constructor
    this.breed = breed;
  }

  speak() { // Overrides the parent method
    console.log(`${this.name} barks.`);
  }

  fetch() {
    console.log(`${this.name} is fetching the ball!`);
  }
}

const myDog = new Dog('Buddy', 'Golden Retriever');
myDog.speak(); // Output: "Buddy barks."
myDog.fetch(); // Output: "Buddy is fetching the ball!"

இந்த மாதிரியில், Dog கிளாஸ் தானாகவே Animal-இலிருந்து name பண்பையும் speak மெத்தடையும் பெறுகிறது. அது தனது சொந்த மெத்தடுகளை (fetch) சேர்க்கலாம் மற்றும் ஏற்கனவே உள்ளவற்றை மேலெழுதலாம். இது ஒரு கடுமையான படிநிலையை உருவாக்குகிறது.

ரியாக்டில் மரபுரிமை ஏன் தடுமாறுகிறது

இந்த 'is-a' மாதிரி சில தரவு கட்டமைப்புகளுக்கு வேலை செய்தாலும், ரியாக்டில் உள்ள UI காம்போனென்டுகளுக்குப் பயன்படுத்தும்போது இது குறிப்பிடத்தக்க சிக்கல்களை உருவாக்குகிறது:

• இறுக்கமான பிணைப்பு: ஒரு காம்போனென்ட் ஒரு பேஸ் காம்போனென்டிலிருந்து மரபுரிமையாக வரும்போது, அது அதன் பேரண்ட்டின் செயலாக்கத்துடன் இறுக்கமாக பிணைக்கப்படுகிறது. பேஸ் காம்போனென்டில் ஏற்படும் ஒரு மாற்றம், சங்கிலித் தொடரில் உள்ள பல சைல்டு காம்போனென்டுகளை எதிர்பாராதவிதமாக உடைக்கக்கூடும். இது ரீஃபாக்டரிங் மற்றும் பராமரிப்பை ஒரு பலவீனமான செயல்முறையாக மாற்றுகிறது.
• நெகிழ்வற்ற லாஜிக் பகிர்தல்: டேட்டா ஃபெட்சிங் போன்ற ஒரு குறிப்பிட்ட செயல்பாட்டை, ஒரே 'is-a' படிநிலையில் பொருந்தாத காம்போனென்டுகளுடன் பகிர விரும்பினால் என்ன செய்வது? உதாரணமாக, ஒரு UserProfile மற்றும் ஒரு ProductList ஆகிய இரண்டிற்கும் டேட்டாவைப் பெற வேண்டியிருக்கலாம், ஆனால் அவை ஒரு பொதுவான DataFetchingComponent-இலிருந்து மரபுரிமையாக வருவதில் எந்த அர்த்தமும் இல்லை.
• ப்ராப்-டிரில்லிங் சிக்கல்: ஒரு ஆழமான மரபுரிமைச் சங்கிலியில், ஒரு உயர்-நிலை காம்போனென்டில் இருந்து ஆழமாக உள்ள ஒரு சைல்டுக்கு ப்ராப்ஸ்களை அனுப்புவது கடினமாகிறது. நீங்கள் அவற்றை பயன்படுத்தாத இடைநிலை காம்போனென்டுகள் வழியாகவும் ப்ராப்ஸ்களை அனுப்ப வேண்டியிருக்கும், இது குழப்பமான மற்றும் வீங்கிய குறியீட்டிற்கு வழிவகுக்கும்.
• "கொரில்லா-வாழைப்பழம் சிக்கல்": OOP நிபுணர் ஜோ ஆம்ஸ்ட்ராங்கின் ஒரு பிரபலமான மேற்கோள் இந்த சிக்கலை மிகச்சரியாக விவரிக்கிறது: "நீங்கள் ஒரு வாழைப்பழம் விரும்பினீர்கள், ஆனால் உங்களுக்கு கிடைத்தது வாழைப்பழத்தை வைத்திருக்கும் ஒரு கொரில்லா மற்றும் முழு காடும்." மரபுரிமையுடன், நீங்கள் விரும்பும் செயல்பாட்டின் ஒரு பகுதியை மட்டும் பெற முடியாது; முழு சூப்பர்கிளாஸையும் அதனுடன் கொண்டு வர நீங்கள் கட்டாயப்படுத்தப்படுகிறீர்கள்.

இந்த சிக்கல்களால், ரியாக்ட் குழு ஒரு நெகிழ்வான மற்றும் சக்திவாய்ந்த முன்னுதாரணத்தை சுற்றி நூலகத்தை வடிவமைத்துள்ளது: கலவை.

ரியாக்ட் வழியைத் தழுவுதல்: கலவையின் சக்தி

கலவை என்பது 'has-a' அல்லது 'uses-a' உறவை ஆதரிக்கும் ஒரு வடிவமைப்பு கொள்கையாகும். ஒரு காம்போனென்ட் மற்றொரு காம்போனென்டாக இருப்பதற்குப் பதிலாக, அது மற்ற காம்போனென்டுகளைக் கொண்டுள்ளது அல்லது அவற்றின் செயல்பாடுகளைப் பயன்படுத்துகிறது. காம்போனென்டுகள் லெகோ செங்கற்களைப் போன்ற கட்டுமானத் தொகுதிகளாகக் கருதப்படுகின்றன - அவை ஒரு கடுமையான படிநிலையில் சிக்காமல் சிக்கலான UI-களை உருவாக்க பல்வேறு வழிகளில் இணைக்கப்படலாம்.

ரியாக்டின் கலவை மாதிரி நம்பமுடியாத அளவிற்கு பல்துறை வாய்ந்தது, மேலும் இது பல முக்கிய பேட்டர்ன்களில் வெளிப்படுகிறது. மிகவும் அடிப்படையானது முதல் மிகவும் நவீனமானது மற்றும் சக்திவாய்ந்தது வரை அவற்றை ஆராய்வோம்.

நுட்பம் 1: `props.children` உடன் உள்ளடக்கம் (Containment)

கலவையின் மிகவும் நேரடியான வடிவம் உள்ளடக்கம். இங்கு ஒரு காம்போனென்ட் ஒரு பொதுவான கொள்கலன் அல்லது 'பெட்டி'யாக செயல்படுகிறது, மேலும் அதன் உள்ளடக்கம் ஒரு பேரண்ட் காம்போனென்டில் இருந்து அனுப்பப்படுகிறது. இதற்காக ரியாக்டில் ஒரு சிறப்பு, உள்ளமைக்கப்பட்ட ப்ராப் உள்ளது: props.children.

எந்தவொரு உள்ளடக்கத்தையும் ஒரு நிலையான பார்டர் மற்றும் நிழலுடன் சுற்றிக்கொள்ளக்கூடிய ஒரு `Card` காம்போனென்ட் உங்களுக்குத் தேவை என்று கற்பனை செய்து பாருங்கள். மரபுரிமை மூலம் `TextCard`, `ImageCard`, மற்றும் `ProfileCard` வகைகளை உருவாக்குவதற்குப் பதிலாக, நீங்கள் ஒரு பொதுவான `Card` காம்போனென்டை உருவாக்குகிறீர்கள்.

// Card.js - A generic container component
function Card(props) {
  return (
    <div className="card">
      {props.children}
    </div>
  );
}

// App.js - Using the Card component
function App() {
  return (
    <div>
      <Card>
        <h1>Welcome!</h1>
        <p>This content is inside a Card component.</p>
      </Card>

      <Card>
        <img src="/path/to/image.jpg" alt="An example image" />
        <p>This is an image card.</p>
      </Card>
    </div>
  );
}

இங்கே, Card காம்போனென்டிற்கு அது என்ன கொண்டிருக்கிறது என்பது தெரியாது அல்லது அதைப் பற்றி கவலைப்படாது. அது வெறுமனே உறை ஸ்டைலிங்கை வழங்குகிறது. திறக்கும் மற்றும் மூடும் <Card> குறிச்சொற்களுக்கு இடையேயான உள்ளடக்கம் தானாகவே props.children ஆக அனுப்பப்படுகிறது. இது découpling மற்றும் மறுபயன்பாட்டிற்கான ஒரு அழகான எடுத்துக்காட்டு.

நுட்பம் 2: ப்ராப்ஸ் உடன் சிறப்புத்தன்மை (Specialization)

சில நேரங்களில், ஒரு காம்போனென்டில் மற்ற காம்போனென்டுகளால் நிரப்பப்பட வேண்டிய பல 'துளைகள்' தேவைப்படலாம். நீங்கள் `props.children` ஐப் பயன்படுத்தலாம் என்றாலும், ஒரு வெளிப்படையான மற்றும் கட்டமைக்கப்பட்ட வழி, காம்போனென்டுகளை வழக்கமான ப்ராப்ஸ்களாக அனுப்புவதாகும். இந்த பேட்டர்ன் பெரும்பாலும் சிறப்புத்தன்மை என்று அழைக்கப்படுகிறது.

ஒரு `Modal` காம்போனென்டை கவனியுங்கள். ஒரு மோடல் பொதுவாக ஒரு தலைப்புப் பகுதி, ஒரு உள்ளடக்கப் பகுதி மற்றும் ஒரு செயல்பாடுகள் பகுதி ( "உறுதிப்படுத்து" அல்லது "ரத்துசெய்" போன்ற பொத்தான்களுடன்) ஆகியவற்றைக் கொண்டுள்ளது. நமது `Modal`-ஐ இந்த பகுதிகளை ப்ராப்ஸ்களாக ஏற்குமாறு வடிவமைக்கலாம்.

// Modal.js - A more specialized container
function Modal(props) {
  return (
    <div className="modal-backdrop">
      <div className="modal-content">
        <div className="modal-header">{props.title}</div>
        <div className="modal-body">{props.body}</div>
        <div className="modal-footer">{props.actions}</div>
      </div>
    </div>
  );
}

// App.js - Using the Modal with specific components
function App() {
  const confirmationTitle = <h2>Confirm Action</h2>;
  const confirmationBody = <p>Are you sure you want to proceed with this action?</p>;
  const confirmationActions = (
    <div>
      <button>Confirm</button>
      <button>Cancel</button>
    </div>
  );

  return (
    <Modal
      title={confirmationTitle}
      body={confirmationBody}
      actions={confirmationActions}
    />
  );
}

இந்த எடுத்துக்காட்டில், Modal என்பது அதிக மறுபயன்பாடு கொண்ட ஒரு லேஅவுட் காம்போனென்ட் ஆகும். அதன் `title`, `body`, மற்றும் `actions` ஆகியவற்றிற்கான குறிப்பிட்ட JSX எலிமெண்ட்களை அனுப்புவதன் மூலம் நாம் அதை சிறப்பிக்கிறோம். இது `ConfirmationModal` மற்றும் `WarningModal` துணைப்பிரிவுகளை உருவாக்குவதை விட மிகவும் நெகிழ்வானது. தேவைக்கேற்ப வெவ்வேறு உள்ளடக்கத்துடன் `Modal`-ஐ நாம் எளிதாக கலக்கிறோம்.

நுட்பம் 3: உயர்-நிலை காம்போனென்டுகள் (HOCs)

டேட்டா ஃபெட்சிங், அங்கீகாரம் அல்லது லாக்கிங் போன்ற UI அல்லாத லாஜிக்கைப் பகிர்ந்து கொள்ள, ரியாக்ட் டெவலப்பர்கள் வரலாற்று ரீதியாக உயர்-நிலை காம்போனென்டுகள் (HOCs) எனப்படும் ஒரு பேட்டர்னைப் பயன்படுத்தினர். நவீன ரியாக்டில் பெரும்பாலும் ஹூக்ஸ் மூலம் மாற்றப்பட்டிருந்தாலும், அவற்றை பு்ரிந்துகொள்வது முக்கியம், ஏனெனில் அவை ரியாக்டின் கலவைக் கதையில் ஒரு முக்கிய பரிணாமப் படியைக் குறிக்கின்றன மற்றும் இன்னும் பல குறியீட்டுத் தளங்களில் உள்ளன.

ஒரு HOC என்பது ஒரு காம்போனென்டை ஒரு ஆர்குமெண்டாக எடுத்து, ஒரு புதிய, மேம்படுத்தப்பட்ட காம்போனென்டைத் திருப்பியளிக்கும் ஒரு ஃபங்ஷன் ஆகும்.

`withLogger` என்ற HOC-ஐ உருவாக்குவோம், அது ஒரு காம்போனென்ட் புதுப்பிக்கப்படும் போதெல்லாம் அதன் ப்ராப்ஸ்களை லாக் செய்கிறது. இது பிழைத்திருத்தத்திற்கு பயனுள்ளதாக இருக்கும்.

// withLogger.js - The HOC
import React, { useEffect } from 'react';

function withLogger(WrappedComponent) {
  // It returns a new component...
  return function EnhancedComponent(props) {
    useEffect(() => {
      console.log('Component updated with new props:', props);
    }, [props]);

    // ... that renders the original component with the original props.
    return <WrappedComponent {...props} />;
  };
}

// MyComponent.js - A component to be enhanced
function MyComponent({ name, age }) {
  return (
    <div>
      <h1>Hello, {name}!</h1>
      <p>You are {age} years old.</p>
    </div>
  );
}

// Exporting the enhanced component
export default withLogger(MyComponent);

`withLogger` ஃபங்ஷன் `MyComponent`-ஐ சுற்றிக் கொள்கிறது, `MyComponent`-இன் உள் குறியீட்டை மாற்றாமல் புதிய லாக்கிங் திறன்களை அதற்கு வழங்குகிறது. இதே HOC-ஐ வேறு எந்த காம்போனென்டிற்கும் அதே லாக்கிங் அம்சத்தை வழங்கப் பயன்படுத்தலாம்.

HOCs உடன் உள்ள சவால்கள்:

• உறை நரகம் (Wrapper Hell): ஒரு காம்போனென்டில் பல HOC-களைப் பயன்படுத்துவது ரியாக்ட் டெவலப்பர் கருவிகளில் ஆழமாக உள்ளமைக்கப்பட்ட காம்போனென்டுகளை விளைவிக்கலாம் (எ.கா., `withAuth(withRouter(withLogger(MyComponent)))`), இது பிழைத்திருத்தத்தை கடினமாக்குகிறது.
• ப்ராப் பெயர் மோதல்கள்: ஒரு HOC, மூடப்பட்ட காம்போனென்டால் ஏற்கனவே பயன்படுத்தப்படும் ஒரு ப்ராப்பை (எ.கா., `data`) செலுத்தினால், அது தற்செயலாக மேலெழுதப்படலாம்.
• மறைமுகமான லாஜிக்: ஒரு காம்போனென்டின் ப்ராப்ஸ் எங்கிருந்து வருகின்றன என்பது அதன் குறியீட்டிலிருந்து எப்போதும் தெளிவாகத் தெரிவதில்லை. லாஜிக் HOC-க்குள் மறைக்கப்பட்டுள்ளது.

நுட்பம் 4: ரெண்டர் ப்ராப்ஸ் (Render Props)

ரெண்டர் ப்ராப் பேட்டர்ன், HOCs-இன் சில குறைபாடுகளுக்கு ஒரு தீர்வாக உருவானது. இது லாஜிக்கைப் பகிர்ந்து கொள்ள ஒரு வெளிப்படையான வழியை வழங்குகிறது.

ஒரு ரெண்டர் ப்ராப் கொண்ட காம்போனென்ட், ஒரு ஃபங்ஷனை ப்ராப் ஆக (பொதுவாக `render` என்று பெயரிடப்படும்) எடுத்து, என்ன ரெண்டர் செய்ய வேண்டும் என்பதைத் தீர்மானிக்க அந்த ஃபங்ஷனை அழைக்கிறது, எந்தவொரு ஸ்டேட் அல்லது லாஜிக்கையும் அதற்கு ஆர்குமெண்டுகளாக அனுப்புகிறது.

சுட்டியின் X மற்றும் Y ஆயங்களை கண்காணித்து, அவற்றைப் பயன்படுத்த விரும்பும் எந்தவொரு காம்போனென்டிற்கும் அவற்றை கிடைக்கச் செய்யும் ஒரு `MouseTracker` காம்போனென்டை உருவாக்குவோம்.

// MouseTracker.js - Component with a render prop
import React, { useState, useEffect } from 'react';

function MouseTracker({ render }) {
  const [position, setPosition] = useState({ x: 0, y: 0 });

  const handleMouseMove = (event) => {
    setPosition({ x: event.clientX, y: event.clientY });
  };

  useEffect(() => {
    window.addEventListener('mousemove', handleMouseMove);
    return () => {
      window.removeEventListener('mousemove', handleMouseMove);
    };
  }, []);

  // Call the render function with the state
  return render(position);
}

// App.js - Using the MouseTracker
function App() {
  return (
    <div>
      <h1>Move your mouse around!</h1>
      <MouseTracker
        render={mousePosition => (
          <p>The current mouse position is ({mousePosition.x}, {mousePosition.y})</p>
        )}
      />
    </div>
  );
}

இங்கே, `MouseTracker` சுட்டி இயக்கத்தைக் கண்காணிப்பதற்கான அனைத்து லாஜிக்கையும் உள்ளடக்கியுள்ளது. அது தானாக எதையும் ரெண்டர் செய்யாது. அதற்குப் பதிலாக, அது ரெண்டரிங் லாஜிக்கை அதன் `render` ப்ராப்பிற்கு ஒப்படைக்கிறது. இது HOC-களை விட வெளிப்படையானது, ஏனெனில் `mousePosition` டேட்டா எங்கிருந்து வருகிறது என்பதை நீங்கள் JSX-க்கு உள்ளேயே துல்லியமாகப் பார்க்க முடியும்.

`children` ப்ராப்பையும் ஒரு ஃபங்ஷனாகப் பயன்படுத்தலாம், இது இந்த பேட்டர்னின் ஒரு பொதுவான மற்றும் நேர்த்தியான மாறுபாடாகும்:

// Using children as a function
<MouseTracker>
  {mousePosition => (
    <p>The current mouse position is ({mousePosition.x}, {mousePosition.y})</p>
  )}
</MouseTracker>

நுட்பம் 5: ஹூக்ஸ் (நவீன மற்றும் விரும்பப்படும் அணுகுமுறை)

ரியாக்ட் 16.8-ல் அறிமுகப்படுத்தப்பட்ட ஹூக்ஸ், நாம் ரியாக்ட் காம்போனென்டுகளை எழுதும் விதத்தில் புரட்சியை ஏற்படுத்தியது. அவை ஃபங்ஷனல் காம்போனென்டுகளில் ஸ்டேட் மற்றும் பிற ரியாக்ட் அம்சங்களைப் பயன்படுத்த உங்களை அனுமதிக்கின்றன. மிக முக்கியமாக, கஸ்டம் ஹூக்ஸ், காம்போனென்டுகளுக்கு இடையில் ஸ்டேட்ஃபுல் லாஜிக்கைப் பகிர்ந்து கொள்வதற்கான மிக நேர்த்தியான மற்றும் நேரடியான தீர்வை வழங்குகின்றன.

ஹூக்ஸ், HOCs மற்றும் ரெண்டர் ப்ராப்ஸின் சிக்கல்களை மிகவும் தூய்மையான முறையில் தீர்க்கின்றன. நமது `MouseTracker` உதாரணத்தை `useMousePosition` என்ற கஸ்டம் ஹூக்காக மாற்றுவோம்.

// hooks/useMousePosition.js - A custom Hook
import { useState, useEffect } from 'react';

export function useMousePosition() {
  const [position, setPosition] = useState({ x: 0, y: 0 });

  useEffect(() => {
    const handleMouseMove = (event) => {
      setPosition({ x: event.clientX, y: event.clientY });
    };

    window.addEventListener('mousemove', handleMouseMove);
    return () => {
      window.removeEventListener('mousemove', handleMouseMove);
    };
  }, []); // Empty dependency array means this effect runs only once

  return position;
}

// DisplayMousePosition.js - A component using the Hook
import { useMousePosition } from './hooks/useMousePosition';

function DisplayMousePosition() {
  const position = useMousePosition(); // Just call the hook!

  return (
    <p>
      The mouse position is ({position.x}, {position.y})
    </p>
  );
}

// Another component, maybe an interactive element
import { useMousePosition } from './hooks/useMousePosition';

function InteractiveBox() {
  const { x, y } = useMousePosition();

  const style = {
    position: 'absolute',
    top: y - 25, // Center the box on the cursor
    left: x - 25,
    width: '50px',
    height: '50px',
    backgroundColor: 'lightblue',
  };

  return <div style={style} />;
}

இது ஒரு மிகப்பெரிய முன்னேற்றம். 'உறை நரகம்' இல்லை, ப்ராப் பெயர் மோதல்கள் இல்லை, மற்றும் சிக்கலான ரெண்டர் ப்ராப் ஃபங்ஷன்கள் இல்லை. லாஜிக் முற்றிலும் ஒரு மறுபயன்பாட்டு ஃபங்ஷனில் (`useMousePosition`) பிரிக்கப்பட்டுள்ளது, மேலும் எந்தவொரு காம்போனென்டும் அந்த ஸ்டேட்ஃபுல் லாஜிக்கில் ஒரே, தெளிவான குறியீட்டு வரியுடன் 'ஹூக்' செய்ய முடியும். கஸ்டம் ஹூக்ஸ் நவீன ரியாக்டில் கலவையின் இறுதி வெளிப்பாடாகும், இது உங்கள் சொந்த மறுபயன்பாட்டு லாஜிக் தொகுதிகளின் நூலகத்தை உருவாக்க உங்களை அனுமதிக்கிறது.

ஒரு விரைவான ஒப்பீடு: ரியாக்டில் கலவை vs. மரபுரிமை

ரியாக்ட் சூழலில் உள்ள முக்கிய வேறுபாடுகளைச் சுருக்கமாகக் கூற, இங்கே ஒரு நேரடி ஒப்பீடு:

அம்சம்	மரபுரிமை (ரியாக்டில் ஒரு ஆன்டி-பேட்டர்ன்)	கலவை (ரியாக்டில் விரும்பப்படுவது)
உறவு	'is-a' உறவு. ஒரு சிறப்பு வாய்ந்த காம்போனென்ட் is a ஒரு பேஸ் காம்போனென்டின் பதிப்பாகும்.	'has-a' அல்லது 'uses-a' உறவு. ஒரு சிக்கலான காம்போனென்ட் has சிறிய காம்போனென்டுகளைக் கொண்டுள்ளது அல்லது uses பகிரப்பட்ட லாஜிக்கைப் பயன்படுத்துகிறது.
பிணைப்பு	அதிகம். சைல்டு காம்போனென்டுகள் அவற்றின் பேரண்ட்டின் செயலாக்கத்துடன் இறுக்கமாகப் பிணைக்கப்பட்டுள்ளன.	குறைவு. காம்போனென்டுகள் சுதந்திரமானவை மற்றும் மாற்றம் இல்லாமல் வெவ்வேறு சூழல்களில் மீண்டும் பயன்படுத்தப்படலாம்.
நெகிழ்வுத்தன்மை	குறைவு. கடுமையான, கிளாஸ் அடிப்படையிலான படிநிலைகள் வெவ்வேறு காம்போனென்ட் மரங்கள் முழுவதும் லாஜிக்கைப் பகிர்வதை கடினமாக்குகின்றன.	அதிகம். லாஜிக் மற்றும் UI-ஐ கட்டுமானத் தொகுதிகள் போல எண்ணற்ற வழிகளில் இணைத்து மீண்டும் பயன்படுத்தலாம்.
குறியீடு மறுபயன்பாடு	முன்வரையறுக்கப்பட்ட படிநிலைக்குள் வரையறுக்கப்பட்டுள்ளது. நீங்கள் "வாழைப்பழத்தை" மட்டும் விரும்பும்போது முழு "கொரில்லாவையும்" பெறுகிறீர்கள்.	சிறந்தது. சிறிய, கவனம் செலுத்திய காம்போனென்டுகள் மற்றும் ஹூக்ஸை முழு பயன்பாட்டிலும் பயன்படுத்தலாம்.
ரியாக்ட் மரபு	அதிகாரப்பூர்வ ரியாக்ட் குழுவால் ஊக்கவிக்கப்படவில்லை.	ரியாக்ட் பயன்பாடுகளை உருவாக்குவதற்கான பரிந்துரைக்கப்பட்ட மற்றும் மரபு சார்ந்த அணுகுமுறை.

முடிவுரை: கலவையில் சிந்தியுங்கள்

கலவை மற்றும் மரபுரிமைக்கு இடையேயான விவாதம் மென்பொருள் வடிவமைப்பில் ஒரு அடிப்படை தலைப்பு. கிளாசிக்கல் OOP-ல் மரபுரிமைக்கு அதன் இடம் இருந்தாலும், UI மேம்பாட்டின் மாறும், காம்போனென்ட்-அடிப்படையிலான தன்மை அதை ரியாக்டிற்கு ஒரு மோசமான பொருத்தமாக ஆக்குகிறது. இந்த நூலகம் அடிப்படையில் கலவையைத் தழுவுவதற்காக வடிவமைக்கப்பட்டது.

கலவையை விரும்புவதன் மூலம், நீங்கள் பெறுவது:

• நெகிழ்வுத்தன்மை: தேவைக்கேற்ப UI மற்றும் லாஜிக்கைக் கலந்து பொருத்தக்கூடிய திறன்.
• பராமரிப்புத்திறன்: தளர்வாகப் பிணைக்கப்பட்ட காம்போனென்டுகளைத் தனித்தனியாகப் புரிந்துகொள்வது, சோதிப்பது மற்றும் ரீஃபாக்டர் செய்வது எளிது.
• அளவிடுதல்: ஒரு கலவை மனப்பான்மை, சிறிய, மீண்டும் பயன்படுத்தக்கூடிய காம்போனென்டுகள் மற்றும் ஹூக்ஸ் ஆகியவற்றின் வடிவமைப்பு அமைப்பை உருவாக்க ஊக்குவிக்கிறது, இது பெரிய, சிக்கலான பயன்பாடுகளை திறமையாக உருவாக்கப் பயன்படுகிறது.

ஒரு உலகளாவிய ரியாக்ட் டெவலப்பராக, கலவையில் தேர்ச்சி பெறுவது சிறந்த நடைமுறைகளைப் பின்பற்றுவது மட்டுமல்ல - இது ரியாக்டை அத்தகைய சக்திவாய்ந்த மற்றும் உற்பத்தித்திறன் மிக்க கருவியாக மாற்றும் முக்கிய தத்துவத்தைப் புரிந்துகொள்வதாகும். சிறிய, கவனம் செலுத்திய காம்போனென்டுகளை உருவாக்குவதன் மூலம் தொடங்குங்கள். பொதுவான கொள்கலன்களுக்கு `props.children`-ஐயும், சிறப்புத்தன்மைக்கு ப்ராப்ஸ்களையும் பயன்படுத்தவும். லாஜிக்கைப் பகிர்ந்து கொள்ள, முதலில் கஸ்டம் ஹூக்ஸை அணுகவும். கலவையில் சிந்திப்பதன் மூலம், காலத்தின் சோதனையைத் தாங்கும் நேர்த்தியான, வலுவான மற்றும் அளவிடக்கூடிய ரியாக்ட் பயன்பாடுகளை உருவாக்கும் பாதையில் நீங்கள் சிறப்பாக முன்னேறுவீர்கள்.