LOPETA Redux-käytön sokealta käytöltä!
Laiskana kehittäjänä — en ostanut sitä. Minusta tuntui, että oletusarvoinen state ja context olivat paljon parempia. Reduxissa oli liian paljon boilerplate-koodia, ja huolimatta siitä, että concerns-jako oli pätevä, sen olisi voinut toteuttaa yhtä helposti mukautetulla hookillakin. Käytimme myös redux-sagaa kommunikointiin backendin kanssa. Minulle se tuntui toiselta täysin tarpeettomalta rasitteelta.
Mutta olin uransa alussa — joten ajattelin antaa sille reilun mahdollisuuden. Käytin reduxia ja redux-sagaa noin vuoden. Ja argumenttini sitä vastaan vain vahvistuivat. Jatkoin kysymisen — miksi käytämme reduxia, ja seniorit vastasivat minulle asioilla kuten —
- Se tekee koodista helpommin testattavaa
- Se erottaa liiketoimintalogiikan komponentin logiikasta
- On suositeltavaa, ettei käytetä useStateta monimutkaisille datatyypeille (kuten objektit tai objektitaulukot)
- redux-saga voi antaa sinulle enemmän hallintaa API-tilasta
- Voisit käyttää contextia, mutta kuinka moneen context-providerin sisään käärit sovelluksesi?
Kaikkiin näihin minulla oli vastaukset, mutta ei kovin vakuuttavia. Redux oli redux — sitä käytti miljoona kehittäjää ja suuret yritykset — ja minä olin vain junior-ohjelmistosuunnittelija, joka oli turhautunut boilerplate-koodiin.
Nyt, sen jälkeen kun olen työskennellyt tiimin johtajana, voin varmuudella sanoa, että seniorit olivat täysin väärässä — ja he olisivat samaa mieltä. Syy tämän artikkelin kirjoittamiseen on se, että nykyäänkin on niin paljon yrityksiä, jotka käyttävät reduxia ja hyväksyvät sen sokeasti standardina. Meidän pitää pysähtyä ja katsoa, mitä vaihtoehtoja meillä on!
Aluksi ymmärretään paremmin, mikä minulla on ongelmana reduxin kanssa. Tässä on koodin määrä, joka meidän pitäisi kirjoittaa yksinkertaiselle count-tilalle käyttämällä reduxia. Tietysti tämä on vain esimerkki — se ei näytä oikeaa sovellusta, mutta se on melko tehokas.
// src/actionConstants.js
const ACTION_CONSTANTS = {
INCREMENT_COUNT: "INCREMENT_COUNT",
DECREMENT_COUNT: "DECREMENT_COUNT",
RESET_COUNT: "RESET_COUNT"
}
// src/store/countStore/reducer.js
const initialState = { count: 0 }
export const countReducer = (state = initialState, action) => {
switch (action.type){
case ACTION_CONSTANTS.INCREMENT_COUNT:
return { count: state.count + 1 };
case ACTION_CONSTANTS.DECREMENT_COUNT:
return { count: state.count - 1 };
case ACTION_CONSTANTS.RESET_COUNT:
return initialState;
}
}
// src/store/countStore/selectors.js
export const useCountReducer = () => {
return useSelector(store => store.countReducer)
}
// src/store/countStore/actions.js
export const incrementCount = () => ({
type: ACTION_CONSTANTS.INCREMENT_COUNT
})
export const decrementCount = () => ({
type: ACTION_CONSTANTS.DECREMENT_COUNT
})
export const resetCount = () => ({
type: ACTION_CONSTANTS.RESET_COUNT
})
// src/store/index.js
const rootReducer = combineReducers({ countReducer: countReducer, ... });
Eikö se ole vain hirveää? Tämä ei vielä ota huomioon koodia, joka menee sagaan tai thunkiin kommunikoitaessa backendin kanssa — tämä on vain tavalliseen jaettuun tilaan — count. Kuvittele, kuinka paljon vaivaa sinun pitää käydä läpi vain tehdäksesi pienen muutoksen logiikkaan — siirtymällä tiedostosta toiseen ja varmistamalla, että muutokset ovat yhdenmukaiset tiedostojen välillä.
Redux on tarkoitettu globaaliksi varastoksi. Sitä käytetään tilan jakamiseen kaikkien sovelluksesi komponenttien välillä. Mutta ongelma on, että kun yritykset alkavat käyttää reduxia, he pyrkivät varastoimaan kaikki API-tilansa (jotka 'saattavat' joutua jakamaan tulevaisuudessa) käyttämällä reduxia. Tämä on järkevää projektissa, jossa monet ihmiset tulevat työskentelemään — ja haluat yhden johdonmukaisen tavan kirjoittaa koodia. Kuitenkin se lisää koodin kokoa ja vähentää sen ylläpidettävyyttä dramaattisesti.
Vaikka he ovat ottaneet käyttöön redux-toolkitin ja se siivoa koodia jonkin verran — se ei silti vertaudu moniin muihin kirjastoihin, jotka auttavat tekemään työn paljon paremmin. Tässä on pinoksi, jota käytämme My Next Developer-ssa:
React-Query: Käytän react-querya hallinnoimaan kaikkia API-tiloja sovelluksissani. Se hallitsee sisäisesti lataamista, virheita ja onnistumistiloja kaikille API-kutsuille, välimuistii tuloksia välttääkseen uudelleenhakua ja tekee tietojen käyttämisen helpoksi useiden komponenttien välillä. Tämä on kaunis työkalu — kun käytät sitä, lupaan ettei halua palata takaisin. Yksinkertainen dokumentaatio ja hooks-pohjainen toteutus tekevät siitä hyvin puhtaan. Tässä on suosittu YouTube-soittolista React Query -opas aloittelijoille Codevolution-kanavalta oppiaksesi react-queryn.
Context: On hyvin harvinaisia tapauksia, joissa meillä on ei-API-pohjainen globaali tila, joka pitää jakaa useiden komponenttien välillä. Näissä harvoissa tapauksissa context on helpoin toteuttaa. Se ei myöskään turhaan lisää toista kirjastoa joukkoon.
Oletko eri mieltä? Haluaisin kuulla ajatuksesi!
