A React csapata nemrégiben kiadta az RFC-t az új React Hooks API-hoz. Ezzel egy időben a Recompose (HOCs tool belt for React) szerzője „kijelentette a fejlesztés végét” ennek a könyvtárnak. Úgy tűnik, ez a két esemény nem véletlen egybeesés, hanem a HOC-korszak végének bizonyítéka a Reactban. És most nekünk, fejlesztőknek azt javasoljuk, hogy a React Hooks használatát az Újrakompozíció helyett a munkafolyamatunkban használjuk. Lássuk, mennyire különböznek a példákon.
A horgok kötelező módon kódolásra kényszerítenek
A compose() a Recompose egyik legértékesebb HOC-ja, amely lehetővé teszi új, összetettebb HOC-ok deklaratív módon történő építését, és nincs analógja az új React Hooks API-ban. Ez nem hátrány, hanem a tervezés miatt. Ezzel az új Hooks API-val nincs szüksége a függvények összeállítására, csak egyenként hívja meg a hookokat az összetevő függvény törzsében, és ezek hatásait és értékeit a rendszer összesíti és alkalmazza az összetevőre. Annak érdekében, hogy a komplex logikát újrafelhasználható egységekre lehessen szétválasztani, minden hook-hívás áthelyezhető egy új függvénybe, amelyet a többi hook-hoz hasonlóan a megcélzott komponens függvénytörzsben kell meghívni. Annak ellenére, hogy a Hooks API deklaratív, bizonyos kötelező módszerekre kényszeríti a fejlesztőket.
A Hooks API-ban nincs a branch() analógja. Az Újrakompozíció nélkül kifejezetten a if vagy más feltételes operátorokat kell használnia.
Egy másik dolog, ami hiányozni fog az újrakompozíció nélkül, az a withPropsOnChange(). Helyettesíthető a useEffect(fn, [changed, values]) és useState() kombinációjával.
Ez csak néhány egyszerű példa. Sokkal több olyan helyzet van, amikor az elegáns deklaratív megoldásokat le kell cserélnie az új imperative API-val.
A horgok nem elég egyértelműek
Rendben, a useState() és néhány másik elég egyértelmű. De eltartott egy ideig, míg rájöttem, hogy a useEffect() a componentDidMount() helyett []-re kerül a második paraméter helyett. E második paraméter nélkül a visszahívás minden tulajdonság változása esetén aktiválódik. Miért ne adjunk hozzá olyan horgokat, amelyeket ugyanúgy neveznek el, mint az osztálymetódusokat, amelyeket mindenki ismer?
A HOC-k fő problémája az, hogy a komponensek összetételének növekedésével a kellékek áramlása nehezen kiszámíthatóvá válik. Egy megfelelő karbantartás nélküli kódban könnyen eltévedhet az ember, miközben megpróbálja kitalálni, hogy melyik kellék melyik HOC-ból származik.
A Recompose Atomic egységeinél nincs ilyen probléma, mivel minden új kellékeket hozzáadó HOC-nak kifejezetten neveket kell adnia ezekhez a kellékekhez. A probléma a nagyobb egyedi HOC-k esetében merül fel, amelyek előre meghatározott nevekkel és értékekkel látják el a gyerekeket.
A horgok megoldják ezt a problémát a belső logikai tulajdonságok áthelyezésével (az Újrakompozícióban minden a kellékekben van tárolva) egy függvény helyi változóiba. Most már könnyen meg lehet különböztetni a „privát” változókat és metódusokat az üzleti logikai kellékektől, amelyek az anyanyelvükből kerültek be a komponensbe.
Következtetés
A HOC megközelítés annak minden hátrányával pusztán funkcionális módja a React alkalmazások kódolásának. Gondos karbantartással és kódolási konvenciókkal robusztus deklaratív kódot eredményez. Ezért szomorú látni, hogy a közösség elutasítja a HOC-k használatát, és a szállítók abbahagyják könyvtáraik ebbe az irányba való fejlesztését.
Annak ellenére, hogy személy szerint nagy rajongója vagyok a Recompose-nak, nagyon remélem, hogy a Hooks API jó és hasznos helyettesítője lesz a Recompose-nak. Kíváncsian várjuk, hogyan és milyen irányba fog fejlődni!
Az "OttoFeller" egy szoftverfejlesztő cég, amely összetett webalkalmazásokra és ígéretes élvonalbeli technológiákra specializálódott.
