Den bedste måde at arkitektere din Redux-app på

Denne artikel handler om, hvordan man tænker i Redux. Vi vil prøve at forstå, hvordan vi kan udnytte dette vidunderlige bibliotek til at gøre vores applikation mere stabil, robust og vedligeholdelig. Det er sprog agnostisk, men vi vil holde vores anvendelsesområde til Redux med React.

For dem der ikke har brugt Redux før, vil jeg citere fra dokumenterne:

Redux er en forudsigelig tilstandsbeholder til JavaScript-apps.

Det er kun et 2 kb bibliotek, der løser et af de største problemer med at vedligeholde store JavaScript-apps: statsadministration.

Denne artikel handler ikke om Redux, da der allerede er masser af artikler om det. Det handler snarere om, hvordan vi skal visualisere en Redux-app og bruge den effektivt.

Lad os sige, at vi bygger en e-handelsapplikation, hvor den har nogle grundlæggende sider som katalog, produktdetaljer og betalingssucces.

Nedenfor er trådrammerne for, hvordan appen ser ud:

Arkitektur i Redux betyder, at vi skal visualisere applikationen som en enhed, og hver side er en underenhed.

Der er fire trin til at opbygge en Redux-app:

  1. Visualiser tilstandstræet
  2. Design dine reduktionsgear
  3. Implementere handlinger
  4. Implementere præsentation

Trin 1: Visualiser tilstandstræ

Lad os designe vores statstræ fra ovenstående trådrammer.

Dette er det vigtigste skridt. Når vi er færdige med at visualisere vores statstræ, bliver implementering af Redux-teknikker virkelig let! Stiplede cirkler er tilstande, der deles af applikationen, solide cirkler er sidespecifikke tilstande.

Trin 2: Design dine reduktionsgear

Hvis du spekulerer på, hvad en reducering præcist er, vil jeg citere direkte fra dokumenterne:

Reducerer angiver, hvordan applikationens tilstand ændres som reaktion på handlinger, der sendes til butikken. Husk, at handlinger kun beskriver, hvad der skete , men ikke beskriv, hvordan applikationens tilstand ændres.

Hver af de vigtige stater kan have deres egne reduktionsgear. Senere kan vi kombinere dem i en rodreducerende enhed, som til sidst vil definere butikken (applikationens eneste sandhedskilde). Det er her, den virkelige magt kommer ind: Du har total kontrol over dine stater og deres adfærd. Intet overvåges af butikken. Den tavse observatør holder øje.

Lad os tjekke et eksempel på, hvordan man designer en reducer ved hjælp af applikationstilstandstræet, som vi designet ovenfor.

// Root Reducer const rootReducer = combineReducer({ header: headerReducer, login: loginReducer, footer: footerReducer, common: commonReducer, product: productReducer, catalog: catalogReducer, payment: paymentReducer });

Rødreduktionen siger alt. Den indeholder alt, hvad butikken har brug for at vide om applikationen.

Lad os nu se på, hvordan en underenheds headerReducer ser ud.

Husk hvordan vi designet vores overskriftstilstand?

// Header Reducer const headerReducer = combineReducer({ menu: menuReducer, search: searchReducer, location: locationReducer });

Vores reducer er en kopi af det, vi designede tidligere i vores statstræ. Dette er kraften i visualisering.

Læg mærke til, hvordan en reducering indeholder flere reduceringsanordninger. Vi behøver ikke at oprette en enorm reducering. Det kan let opdeles i mindre reduktionsanordninger, da hver har sine individuelle identiteter og har sine egne specifikke operationer. Dette hjælper os med at skabe adskillelse af logik, hvilket er meget vigtigt for vedligeholdelse af store apps.

Lad os nu forstå, hvordan en typisk reduceringsfil skal oprettes, for eksempel searchReducer.

// Search Reducer const initialState = { payload: [], isLoading: false, error: {}}; export function searchReducer( state=initialState, action ) { switch(action.type) { case FETCH_SEARCH_DATA: return { ...state, isLoading: true }; case FETCH_SEARCH_SUCCESS: return { ...state, payload: action.payload, isLoading: false }; case FETCH_SEARCH_FAILURE: return { ...state, error: action.error, isLoading: false }; case RESET_SEARCH_DATA: return { ...state, ...initialState } default: return state; } }

Dette reduceringsmønster definerer de mulige ændringer i sin søgetilstand, når søgning-API kaldes.

FETCH_SEARCH_DATA, FETCH_SEARCH_SUCCESS, FETCH_SEARCH_FAILURE, RESET_SEARCH_DATA

Alle ovenstående er mulige konstanter, der definerer, hvilke mulige handlinger der kan udføres.

Bemærk: Det er vigtigt at opretholde en RESET_SEARCH_DATA-handling, hvis vi har brug for at nulstille data under afmontering af en komponent.

Trin 3: Gennemfør handlinger

Hver handling, der har API-opkald, går normalt gennem tre faser i en app.

  1. Indlæsningstilstand -> FETCH_SEARCH_DATA
  2. Succes -> FETCH_SEARCH_SUCCESS
  3. Fejl -> FETCH_SEARCH_FAILURE

Vedligeholdelse af disse handlingstyper hjælper os med at kontrollere datastrømmen, når en API kaldes i vores app.

Lad os dykke ned i koden for at forstå, hvordan en typisk handling vil se ud.

export function fetchSearchData(args) { return async (dispatch) => { // Initiate loading state dispatch({ type: FETCH_SEARCH_DATA }); try { // Call the API const result = await fetchSearchData( args.pageCount, args.itemsPerPage ); // Update payload in reducer on success dispatch({ type: FETCH_SEARCH_SUCCESS, payload: result, currentPage: args.pageCount }); } catch (err) { // Update error in reducer on failure dispatch({ type: FETCH_SEARCH_FAILURE, error: err }); } }; }

Bemærk, hvordan datastrømmen spores af butikken gennem handlinger. Dette holder hver ændring i appen ansvarlig.

Således skrives lignende handlinger for hver ændring i reduktionsmidler i forskellige stater.

En af de største fordele ved Redux er abstraktionen af ​​hver eneste handling.

Trin 4: Implementere præsentation

import React, { Component } from 'react'; import { connect } from 'react-redux';; import fetchSearchData from './action/fetchSearchData'; import SearchData from './SearchData'; const Search = (props) => (  ); const mapStateToProps = (state) => ({ search: state.header.search.payload }); const mapDispatchToProps = { fetchSearchData}; export default connect(mapStateToProps, mapDispatchToProps)(Search)

As you can see, the presentation component is very simple and easy to understand.

Conclusion

I would like to mention some of the biggest benefits that I found using Redux:

  1. It certainly reduces code smell.
  2. Abstraction of code is easier to achieve.
  3. Redux also introduces us to other principles like immutability, functional programming, and many others.
  4. It allows you to visualise each and every action and track them with “time traveling.”

I hope this article helps you get a clearer picture of why Redux is truly awesome, and how we can utilise the power of visualisation to make maintainable applications.

Follow me on twitter to get more updates regarding new articles and to stay updated in latest frontend developments. Also share this article on twitter to help others know about it. Sharing is caring ^_^.

Nogle nyttige ressourcer

  1. //redux.js.org/
  2. //github.com/reduxjs/redux/blob/master/eksempler
  3. //medium.com/@rajaraodv/a-guide-for-building-a-react-redux-crud-app-7fe0b8943d0f#.c4yhhvk0d

Mine tidligere artikler

  1. //medium.freecodecamp.org/how-to-use-redux-persist-when-migrating-your-states-a5dee16b5ead
  2. //codeburst.io/redux-observable-to-the-redning-b27f07406cf2
  3. //codeburst.io/building-webapp-for-the-future-68d69054cbbd
  4. //codeburst.io/cors-story-of-requesting-twice-85219da7172d