El magatzem de CicloUrbano existeix, arrenca i es veu a DevTools, però està buit: tres slices provisionals amb reducers: {} que no accepten cap acció. Aquesta lliçó l'omple. Aquí és on es fa la feina de veritat de Redux, que no consisteix a configurar res sinó a modelar l'estat i les seves transicions: decidir quina forma té cada domini, quins successos pot rebre i com canvia amb cadascun. Veuràs l'anatomia d'una acció i com anomenar-la, createSlice a fons i tot el que genera per tu, la immutabilitat aparent d'Immer —el mecanisme que més sorprèn a qui ve del Redux clàssic— i l'única regla que no es pot trencar amb ell, la preparació d'accions amb prepare per mantenir els reductors purs, els tres slices complets de CicloUrbano, els selectors com a frontera entre els components i la forma de l'estat, la normalització d'entitats per identificador i la lògica asíncrona amb createAsyncThunk. En acabar, el magatzem tindrà tot el comportament del client de CicloUrbano modelat i provat. Connectar-lo als components continua sent cosa de 07-05: aquí no apareix ni un useSelector.

1. Anatomia d'una acció i com anomenar-la
2. createSlice a fons: què rep i què genera
3. La immutabilitat aparent d'Immer
4. La regla que no es pot trencar
5. Reductors amb preparació: prepare
6. sliceCataleg: filtre, cerca i ordre
7. sliceSessio: usuari i accés
8. sliceReserves: crear, confirmar i cancel·lar
9. Selectors: la frontera amb la forma de l'estat
10. Normalitzar l'estat per identificador
11. createEntityAdapter en resum
12. Lògica asíncrona amb createAsyncThunk
13. extraReducers per reaccionar a altres slices
14. Provar reductors i selectors

Una acció de Redux és un objecte pla amb una forma fixada per convenció:

Anomenar bé és la meitat de la feina. La convenció d'RTK és domini/succésOcorregut:

El prefix del domini no és decoratiu: fa que l'historial de DevTools es llegeixi com una crònica —sessio/sessioIniciada, cataleg/tipusCanviat, reserves/reservaCreada— i que el type sigui únic sense esforç. Amb createSlice no cal que l'escriguis: es genera concatenant el name del slice i el nom del reductor.

Aquesta és la mateixa disciplina de 05-05 —accions en passat que descriuen successos— amb dos ajustos obligatoris de Redux: el camp es diu type i no tipus, i les dades van en payload en lloc de camps solts. Són APIs de la biblioteca i, com la resta del curs, no es tradueixen.

Un slice és «una porció de l'estat amb tot el que la governa»: el seu estat inicial, les seves transicions i, per convenció, els seus selectors. createSlice rep un objecte de configuració:

I retorna un objecte amb tres coses:

Val la pena aturar-se en el que acaba de passar, perquè és la major part de l'estalvi respecte del Redux clàssic. D'una definició de nou línies n'han sortit:

• La constant de tipus 'cataleg/tipusCanviat', que no has escrit i per tant no pots escriure malament.
• El creador d'acció tipusCanviat, que empaqueta el seu argument com a payload.
• El cas del reductor que respon a aquest tipus.
• El default que retorna l'estat intacte quan l'acció no és seva.

En el Redux clàssic això eren tres fitxers i una trentena de línies.

Convenció d'exportació del slice —la que s'usa a tot CicloUrbano i encaixa amb la del projecte («export default per als components i exportació amb nom per a la resta»), amb una excepció pràctica:

El reductor va per defecte perquè cada fitxer de slice en té exactament un, i així l'import reductorCataleg from '…/sliceCataleg.js' del magatzem queda net.

Torna a mirar el reductor de l'apartat anterior:

Això contradiu frontalment el principi 3 de 07-03 i tot el que vas aprendre a 05-01 i 05-05. I tanmateix és correcte, és la forma recomanada i no muta res.

L'explicació és Immer, una biblioteca que RTK inclou i aplica automàticament dins de createSlice. El que passa per sota:

1. Abans de cridar el teu reductor, Immer embolcalla l'estat actual en un esborrany (draft), un objecte proxy que sembla l'estat real.
2. El teu codi escriu sobre l'esborrany: estat.tipus = 'electrica', estat.ids.push('res-02'), delete estat.entitats['res-01'].
3. El proxy no aplica aquests canvis: els anota.
4. En acabar el reductor, Immer construeix un objecte nou aplicant les anotacions, copiant només les branques afectades i reutilitzant les referències de tot el que no ha canviat.

Compara el mateix canvi escrit de les dues formes:

Cinc línies de propagació de ... substituïdes per una que diu exactament el que fa. I l'última fila del diagrama importa per al rendiment: les branques que no es toquen conserven la seva referència, de manera que un component que llegeixi estat.cataleg no veurà cap canvi quan es confirmi una reserva. És el que fa que la comparació per identitat de useSelector (07-05) funcioni tan bé.

Dues precisions perquè el model mental sigui correcte:

• Immer només actua dins de createSlice i createReducer. Un reductor escrit a mà i passat directament a configureStore no té esborrany: allà mutar és mutar, i saltarà l'avís d'immutableCheck que vas veure a 07-03.
• L'esborrany només existeix durant l'execució del reductor. No te'l pots guardar, ni passar-lo a un setTimeout, ni retornar-lo des d'una promesa.

Immer té exactament una regla, i trencar-la produeix fallades difícils d'entendre:

O modifiques l'esborrany, o retornes un estat nou. Mai les dues coses en el mateix reductor.

El cas del reinici mereix atenció perquè és el que més falla:

Reassignar estat és JavaScript bàsic: canvies la variable local, no l'objecte al qual apuntava. Immer no ho pot detectar.

I un tercer cas, el més subtil de tots:

Fora del reductor, ultimEstat apunta a un proxy revocat i qualsevol accés llança Cannot perform 'get' on a proxy that has been revoked. Si necessites l'estat resultant, llegeix-lo del magatzem.

Operacions segures sobre l'esborrany, les que faràs servir cada dia:

El principi 3 diu que un reductor és pur: sense identificadors aleatoris, sense new Date(), sense res no determinista. A 05-05 vas resoldre això generant la reserva al gestor i passant-la ja construïda al reductor. Funciona, però desplaça el problema: cada lloc que creï una reserva ha de recordar construir-la igual.

RTK ofereix una solució millor: la notació de preparació. En comptes d'una funció, un reductor pot ser un objecte amb reducer i prepare.

Què s'hi guanya:

• El reductor continua sent pur, així que es pot provar amb una entrada fixa i continua funcionant el viatge en el temps: en repetir l'historial, l'acció ja té el seu identificador i la seva data gravats, i el resultat és idèntic.
• La construcció està en un únic lloc. El formulari, un botó de «repetir reserva» i una prova creen reserves exactament igual.
• La signatura és còmoda. reservaCreada('bici-002', 'usr-01', …) en lloc d'obligar cada cridador a muntar l'objecte sencer.
• Les dates es guarden com a cadenes ISO, respectant la serialitzabilitat de 07-03.

prepare també pot retornar meta i error a més de payload, tot i que a CicloUrbano no farà falta.

Comencem pel més senzill, que a més prepara el terreny per als selectors derivats.

Dos comentaris sobre decisions concretes:

• filtresReiniciats no retorna ESTAT_INICIAL. Si ho fes, esborraria també les bicicletes carregades i l'estat de càrrega. Modifica els tres camps que li corresponen i deixa la resta intacta: és la regla de l'apartat 4 aplicada amb criteri.
• bicicletes és aquí de forma provisional i amb data de caducitat. Segons la taxonomia de 07-01, és estat del servidor i no hauria de viure en un magatzem de client. Es posa aquí per poder ensenyar createAsyncThunk amb un cas real, i a 07-06 sortirà del slice cap a una memòria cau de consultes. Està bé que ho vegis fer i desfer: és exactament el que passa en un projecte real quan s'introdueix una biblioteca d'estat del servidor.

I una advertència que es resol del tot a 07-05: que tipus existeixi al slice no vol dir que el filtre deixi de viure a la URL. El filtre del catàleg continua sent estat d'URL (06-02, 07-01) i no pot tenir dues fonts de veritat. Com es concilien les dues coses és una decisió que es pren en connectar els components.

Decisions que convé justificar:

• sessioIniciada rep l'usuari complet, no el seu identificador. Buscar l'usuari a usuaris és una operació de cerca que pot fallar i que, quan hi hagi API de veritat, serà asíncrona: no és feina del reductor. Si prefereixes la comoditat de cridar amb l'identificador, és un cas perfecte per a prepare.
• carregant: true com a valor inicial és el carregantSessio de 06-05, i continua sent imprescindible: començar en false faria que RutaProtegida expulsés un usuari amb sessió vàlida durant el primer render.
• esOperari no és a l'estat, és un selector. És l'estat derivat de 07-01 i 05-01 aplicat a Redux: es calcula, no es guarda. Si estigués guardat, caldria recordar-se d'actualitzar-lo a les quatre transicions.

El slice central, ja en forma normalitzada (el perquè és a l'apartat 10).

El cicle de vida d'una reserva queda modelat així:

Dos detalls que marquen la diferència entre un reductor correcte i un de fràgil:

• Les guardes retornen sense fer res (if (!reserva) return;). Dins de createSlice, un return sense valor significa «no canvia res», i Immer retorna el mateix estat. No ho confonguis amb un return undefined explícit en un reductor escrit a mà, on seria un error.
• if (reserva.estat !== 'activa') return; codifica una regla de negoci en l'únic lloc on es pot aplicar sempre. Confirmar una reserva ja cancel·lada deixa de ser possible des de cap punt de l'aplicació, i aquesta garantia és exactament el que es compra amb el principi 2.

Fixa't també que l'esborrany del formulari no és en aquest slice, a diferència del reductorReserves de 05-05. És una decisió deliberada de l'auditoria de 07-01: l'esborrany és estat de formulari, canvia amb cada tecla i no té per què provocar un cicle de comparació a tots els subscriptors del magatzem. Es queda junt al formulari.

Un selector és una funció que rep l'estat i retorna una porció o un derivat d'ell.

Sembla trivial, i tanmateix resol un problema molt car. Sense selectors, els components coneixen la forma exacta de l'estat:

El dia que sessio passi a dir-se autenticacio, o que les reserves deixin d'estar normalitzades, cal buscar i canviar vint components, amb la certesa d'oblidar-ne dos. Amb selectors, la forma de l'estat la coneix un sol fitxer: el del slice.

Per què es declaren junt al slice: el slice és l'únic mòdul que pot canviar la forma de l'estat, així que és l'únic que l'ha de conèixer. Si canvia, se n'actualitzen els selectors i ningú més se n'assabenta. És encapsulació clàssica, aplicada a l'estat.

RTK ofereix la clau selectors dins de createSlice, i té una particularitat molt útil: els selectors declarats allà reben l'estat del slice, no l'estat global, i RTK els adapta automàticament perquè des de fora es cridin amb l'estat complet.

Això funciona perquè createSlice sap sota quina clau es muntarà el slice... sempre que la clau del reducer a configureStore coincideixi amb el name del slice. És un altre motiu perquè coincideixin.

Els interessants són els que calculen en lloc de només llegir. Aquest és el que governa el catàleg de CicloUrbano:

Això és 07-01 portat a Redux: visibles no es guarda, es calcula. No hi ha cap acció visiblesActualitzades ni cap efecte que sincronitzi, així que és impossible que el filtre i la llista es contradiguin.

Però aquest selector té un problema que cal anunciar aquí i resoldre a la propera lliçó: retorna un array nou a cada crida, perquè filter i sort creen arrays nous. Quan l'usis amb useSelector, la comparació per identitat donarà sempre «ha canviat» i el component es repintarà amb cada acció del magatzem, encara que no tingui res a veure amb el catàleg. La solució és createSelector, que memoritza el resultat i només recalcula si canvien les seves entrades. S'explica a fons a 07-05, on la fallada es reprodueix i es corregeix.

seleccionarReservaPerId rep un argument a més de l'estat:

És perfectament vàlid i molt útil. Tingues en compte que un selector així no es pot memoritzar amb createSelector tal qual, perquè la memorització guarda un únic resultat i canviar d'identificador l'invalidaria cada vegada. Per a això existeixen les fàbriques de selectors, un patró que també es veu a 07-05.

Els dos slices amb entitats —reserves ara, i bicicletes mentre sigui aquí— usen la forma { entitats, ids } en lloc d'un array. Això és normalització, i el motiu es veu millor comparant.

L'última fila és la decisiva. Amb un array, confirmar una reserva crea un array nou i tot component que llegeixi la llista es repinta. Normalitzat, canvia una branca d'entitats i les altres conserven la seva referència (apartat 3), de manera que un component que llegeixi entitats['res-07'] no veu cap canvi.

I el motiu de fons: res de dades imbricades. Fixa't que la reserva guarda bicicletaId: 'bici-002' i usuari: 'usr-01', no la bicicleta ni l'usuari complets. Si guardés l'objecte sencer:

• El model de bici-002 estaria duplicat a cada reserva que la fes servir, i actualitzar el preu obligaria a recórrer-les totes.
• Dues reserves podrien mostrar dades diferents de la mateixa bicicleta.
• Una única font de veritat deixaria d'existir, contradient el principi 1.

La regla és la mateixa que en una base de dades relacional: cada entitat una vegada, i les relacions per identificador. Recompondre l'objecte complet per pintar-lo és feina d'un selector derivat, no de l'estat.

ids a part compleix una funció que no es veu a primer cop d'ull: guarda l'ordre. Les claus d'un objecte no garanteixen un ordre útil, així que la seqüència de presentació es representa explícitament com un array de cadenes, barat de copiar i de comparar.

Escriure a mà entitats[id] = x; ids.push(id) a cada reductor és repetitiu i fàcil de desincronitzar. RTK porta createEntityAdapter, que genera aquestes operacions.

Nota important sobre noms: l'adaptador usa entities i ids en anglès, perquè són de l'API de RTK. És el mateix criteri de sempre: les APIs no es tradueixen. Per això els slices escrits a mà d'aquesta lliçó usen entitats, que és un camp nostre, i si adoptes l'adaptador el camp passa a dir-se entities.

A CicloUrbano, amb cinc bicicletes i unes poques reserves, l'adaptador és més maquinària de la necessària i per això els slices d'abans estan escrits a mà: es veu millor el que passa. En una aplicació amb milers d'entitats i mitja dotzena de tipus, createEntityAdapter estalvia molt codi i elimina tota una família de fallades per desincronització entre ids i entitats.

Els reductors són purs: no poden fer peticions. Les peticions es fan en un thunk, una funció que es despatxa en lloc d'un objecte i que rep dispatch i getState. RTK embolcalla el patró en createAsyncThunk.

createAsyncThunk genera tres tipus d'acció a partir del prefix:

Aquestes tres accions no són a reducers perquè no les defineix aquest slice: les defineix el thunk. Es gestionen a extraReducers.

Aquest patró estatCarrega + error és el mateix de useFetchBicicletes (05-06), amb 'inactiu' | 'carregant' | 'correcte' | 'error' com a única variable de fase, i pel mateix motiu: una sola variable fa impossibles els estats contradictoris del tipus «carregant i amb error alhora».

Detalls del thunk que convé fixar:

• utilitats (el segon paràmetre) porta molt més que signal: dispatch per despatxar altres accions, getState per llegir l'estat actual, rejectWithValue per retornar un error controlat i requestId per identificar aquesta execució concreta.
• signal és un AbortSignal: passant-lo a fetch, la petició es cancel·la si el thunk s'avorta. És l'AbortController de 05-02, ja muntat.
• condition evita peticions duplicades, un problema que a 05-02 vas resoldre a mà:

• La funció retorna la dada, no la guarda. El thunk obté; el reductor col·loca. Mantenir aquesta separació és el que permet provar cada part per separat.

Un avís honest, que és el fil cap al final del mòdul: tot això —càrrega, error, cancel·lació, evitar duplicats— és infraestructura que estàs escrivint a mà per a cada recurs. I encara falten la revalidació, la invalidació després d'escriure, els reintents i la memòria cau. Aquesta llista completa és la que justifica la lliçó 07-06.

extraReducers no serveix només per a thunks: serveix perquè un slice respongui a qualsevol acció, incloses les d'un altre domini. És la resposta al senyal 4 de 07-02 («diversos proveïdors necessiten reaccionar al mateix succés»).

Cas concret: en tancar sessió, les reserves de l'usuari han de desaparèixer del magatzem.

El que és important conceptualment: una acció es despatxa una vegada i tots els reductors la veuen. sessioTancada la defineix sliceSessio i també la consumeix sliceReserves, sense que cap dels dos conegui l'altre més enllà de l'import del creador d'acció. És el desacoblament que el context no donava: allà hauries hagut de passar una funció d'un proveïdor a un altre.

Compte amb una dependència circular: sliceReserves importa sessioTancada de sliceSessio. Si sliceSessio importés alguna cosa de sliceReserves, tindries un cicle. La convenció habitual és que les accions «transversals» visquin al slice que les origina i que la resta les importin, mai al revés.

Aquí es cobra la promesa del principi 3: reductors i selectors són funcions pures, així que provar-les és cridar-les i comparar la sortida. Sense React, sense DOM, sense magatzem, sense simulacions.

Fixa't en dues proves especialment valuoses:

• «no muta l'estat rebut» verifica el principi 3 directament. És la xarxa de seguretat davant d'un futur refactor que tregui el reductor de createSlice i perdi Immer.
• «ignora una reserva inexistent» comprova amb toBe que la referència és la mateixa. És la prova que la guarda funciona i que no es generen estats nous innecessaris, la qual cosa al seu torn evita repintats.

Els selectors derivats es proven igual de fàcil:

Aquesta és una de les avantatges més infravalorades de Redux: tota la lògica de negoci queda en funcions pures que es proven sense muntar ni un sol component. Les eines concretes —Jest, asercions, cobertura— són el Mòdul 9; el que interessa avui és que el disseny ho fa possible.

Error 1: mutar i retornar alhora. estat.x = 1; return {…estat} trenca l'única regla d'Immer. O una cosa, o l'altra.

Error 2: reassignar el paràmetre estat. estat = ESTAT_INICIAL no fa res. Per reiniciar, return ESTAT_INICIAL.

Error 3: generar identificadors o dates dins del reductor. Trenca la puresa i amb ella el viatge en el temps i les proves. Va a prepare.

Error 4: guardar estat derivat. Un camp visibles, total o esOperari a l'estat és un camp que algun dia es contradirà amb la seva font. Selector.

Error 5: imbricar entitats completes. Guardar la bicicleta sencera dins de cada reserva duplica dades i trenca la font única de veritat. Guarda bicicletaId i recomposa-ho en un selector.

Error 6: anomenar les accions com a ordres. cataleg/setTipus descriu una assignació; cataleg/tipusCanviat descriu un succés. Amb la segona forma, DevTools es llegeix com una crònica del que ha fet l'usuari.

Error 7: posar els addMatcher abans que els addCase. El constructor d'extraReducers els avalua en ordre i RTK avisa si els barreges malament. Primer els casos concrets, després els matcher, i addDefaultCase al final.

Error 8: initialState compartit per referència. Si diversos slices comparteixen el mateix objecte literal i algun el retorna tal qual des d'un reinici, un canvi posterior podria afectar-los tots dos. Defineix una constant per slice.

Consell 1: un fitxer per slice, i el slice amo de la seva forma. Estat, reductors i selectors junts. Ningú de fora hauria d'escriure estat.reserves.entitats.

Consell 2: escriu primer l'estat inicial, comentat. Decidir la forma abans que les transicions evita refer els reductors tres vegades. Els comentaris de tipus ('activa' | 'confirmada' | 'cancelada') valen el seu pes en or.

Consell 3: prova cada reductor nou el mateix dia. Costa dos minuts perquè són funcions pures, i aquestes proves continuen sent vàlides quan el component que les usa es reescrigui sencer.

Consell 4: posa guardes als reductors que busquen per id. if (!entitat) return; converteix una fallada en un no-canvi. Sense la guarda, una acció amb un identificador obsolet tomba l'aplicació.

Exercici 1. Afegeix a sliceReserves una acció reservaProlongada que sumi hores a una reserva. Requisits: només es pot prolongar una reserva 'activa'; el màxim són 24 hores en total; cal registrar el moment de la prolongació; i si la reserva no existeix o no compleix les condicions, l'estat no ha de canviar. Escriu també dues proves.

Exercici 2. Aquest slice té cinc problemes. Troba'ls i reescriu-lo.

Exercici 3. Escriu un createAsyncThunk anomenat enviarReserva que enviï una reserva nova a POST http://localhost:3001/reservas i gestioni els seus tres estats a sliceReserves usant el camp estatEnviament. Ha de: llegir l'usuari actual del magatzem en lloc de rebre'l com a argument, retornar un error controlat si la resposta no és correcta, i afegir la reserva a l'estat normalitzat quan el servidor la confirmi.

Solució 1.

El moment va a prepare perquè new Date() no pot estar al reductor, i el límit de 24 hores es codifica al reductor —no al component— perquè cap pantalla futura se'l pugui saltar.

Solució 2. Els cinc problemes:

1. ESTABLIR_ESTACIONS: nom en estil de constant i amb forma d'ordre. Ha de ser estacionsRebudes, un succés en passat.
2. totalPlaces és estat derivat guardat al magatzem. És una suma sobre llista: va en un selector.
3. ESTABLIR_ESTACIONS muta i retorna en el mateix reductor: trenca la regla d'Immer.
4. new Date() en dos llocs: a initialState i als reductors. No és serialitzable i no és pur. Cadena ISO, i generada a prepare.
5. reiniciar reassigna el paràmetre, així que no fa res. Ha de retornar l'estat inicial.

I un sisè de propina: seleccionada guarda l'objecte complet, duplicant l'entitat. Ha de guardar l'identificador i recompondre's amb un selector.

Solució 3.

Tres decisions que mereixen comentari:

• getState() dins del thunk evita que cada component hagi de llegir l'usuari i passar-lo. La regla que hi ha darrere: el thunk és el lloc on viu la lògica que necessita llegir l'estat; el reductor només aplica el resultat.
• rejectWithValue enfront de llançar. Llançant, accio.error.message porta el missatge tècnic de l'error (Failed to fetch); amb rejectWithValue controles exactament el text que veurà l'usuari. Per a missatges d'interfície, sempre rejectWithValue.
• La reserva la construeix el thunk, no el reductor ni prepare, perquè qui mana és la resposta del servidor: el fulfilled guarda el que ha retornat l'API, no el que s'ha enviat. Si el servidor assignés el seu propi identificador, això seria imprescindible.

El magatzem de CicloUrbano ja té comportament. Saps que una acció és { type, payload }, que s'anomena domini/succésOcorregut en passat —reserves/reservaConfirmada, cataleg/tipusCanviat, sessio/sessioTancada— i que aquest nomenat és el que converteix l'historial de DevTools en una crònica llegible. createSlice rep name, initialState i reducers i genera d'una sola vegada els tipus, els creadors d'acció, el reductor i el cas per defecte: dels tres o quatre fitxers del Redux clàssic es passa a un de sol. Immer et deixa escriure estat.entitats[id].estat = 'confirmada' dins d'un slice perquè el que toques és un esborrany que anota canvis i produeix un objecte nou copiant només les branques afectades —la resta conserva la seva referència, que és el que farà eficient useSelector—, amb una única regla inviolable: o modifiques l'esborrany o retornes un estat nou, mai les dues coses. I prepare manté la puresa traient del reductor allò no determinista, els identificadors i les dates ISO.

CicloUrbano queda amb tres slices complets: sliceCataleg amb tipus, terme i ordre més la càrrega del catàleg, sliceSessio amb l'usuari, el carregant inicial imprescindible per a RutaProtegida i esOperari com a selector i no com a camp, i sliceReserves amb el cicle activa → confirmada / cancelada, guardes que codifiquen les regles de negoci a l'únic lloc on no es poden saltar, i estat normalitzat { entitats, ids }: cada entitat una vegada, les relacions per identificador —bicicletaId, no la bicicleta sencera— i l'ordre explícit en un array de cadenes. Els selectors viuen junt al seu slice perquè el slice és l'únic que ha de conèixer la forma de l'estat, i els derivats com seleccionarBicicletesVisibles calculen en lloc de guardar, amb l'advertència pendent que retornen un array nou a cada crida. createAsyncThunk resol l'asincronia amb les seves tres accions pending/fulfilled/rejected gestionades a extraReducers amb el patró estatCarrega/error, i extraReducers serveix a més perquè un slice reaccioni a les accions d'un altre sense acoblar-s'hi. Tot això són funcions pures, així que provar-les és cridar-les i comparar, sense React ni DOM.

Falta la part que es veu. A la propera lliçó connectaràs el magatzem als components amb useSelector i useDispatch, i allà apareix la regla d'or que decideix si Redux et repintarà l'aplicació sencera o només el necessari: la comparació per identitat. Veuràs la fallada reproduïda amb seleccionarBicicletesVisibles, les seves quatre solucions incloent-hi la memorització amb createSelector, reescriuràs PaginaCataleg, PaginaReserves, PanellReserves i MenuUsuari, i decidiràs amb arguments què es queda fora del magatzem. La propera lliçó és Redux: Connectar-lo a React.