Melhores redutores com imersão

Como desenvolvedor React, você já deve estar familiarizado com o princípio de que o estado não deve ser modificado diretamente. Você pode estar se perguntando o que isso significa (a maioria de nós teve essa confusão quando começamos).

Este tutorial fará jus a isso: você entenderá o que é estado imutável e a necessidade disso. Você também aprenderá como usar o Immer para trabalhar com estado imutável e os benefícios de usá-lo. Você pode encontrar o código neste artigo neste repositório do Github.

Imutabilidade em JavaScript e por que isso importa

Immer.js é uma pequena biblioteca JavaScript escrita por Michel Weststrate cuja missão declarada é permitir que você “trabalhe com estado imutável de uma maneira mais conveniente”.

Mas antes de mergulhar no Immer, vamos relembrar rapidamente a imutabilidade em JavaScript e por que isso é importante em um aplicativo React.

O mais recente padrão ECMAScript (também conhecido como JavaScript) define nove tipos de dados integrados. Destes nove tipos, há seis que são referidos como valores/tipos primitive . Esses seis primitivos são undefined , number , string , boolean , bigint e symbol . Uma simples verificação com o operador typeof do JavaScript revelará os tipos desses tipos de dados.

 console.log(typeof 5) // number console.log(typeof 'name') // string console.log(typeof (1 < 2)) // boolean console.log(typeof undefined) // undefined console.log(typeof Symbol('js')) // symbol console.log(typeof BigInt(900719925474)) // bigint

Uma primitive é um valor que não é um objeto e não possui métodos. O mais importante para nossa discussão atual é o fato de que o valor de uma primitiva não pode ser alterado depois de criada. Assim, as primitivas são ditas immutable .

Os três tipos restantes são null , object e function . Também podemos verificar seus tipos usando o operador typeof .

 console.log(typeof null) // object console.log(typeof [0, 1]) // object console.log(typeof {name: 'name'}) // object const f = () => ({}) console.log(typeof f) // function

Esses tipos são mutable . Isso significa que seus valores podem ser alterados a qualquer momento após serem criados.

Você pode estar se perguntando por que eu tenho o array [0, 1] lá em cima. Bem, em JavaScriptland, um array é simplesmente um tipo especial de objeto. Caso você também esteja se perguntando sobre null e como ele é diferente de undefined . undefined significa simplesmente que não definimos um valor para uma variável enquanto null é um caso especial para objetos. Se você sabe que algo deve ser um objeto, mas o objeto não está lá, você simplesmente retorna null .

Para ilustrar com um exemplo simples, tente executar o código abaixo no console do seu navegador.

 console.log('aeiou'.match(/[x]/gi)) // null console.log('xyzabc'.match(/[x]/gi)) // [ 'x' ]

String.prototype.match deve retornar uma matriz, que é um tipo de object . Quando não consegue encontrar tal objeto, ele retorna null . Retornar undefined também não faria sentido aqui.

Chega disso. Vamos voltar a discutir a imutabilidade.

De acordo com os documentos do MDN:

“Todos os tipos, exceto objetos, definem valores imutáveis ​​(ou seja, valores que não podem ser alterados).”

Essa instrução inclui funções porque elas são um tipo especial de objeto JavaScript. Veja a definição da função aqui.

Vamos dar uma olhada rápida no que os tipos de dados mutáveis ​​e imutáveis ​​significam na prática. Tente executar o código abaixo no console do seu navegador.

 let a = 5; let b = a console.log(`a: ${a}; b: ${b}`) // a: 5; b: 5 b = 7 console.log(`a: ${a}; b: ${b}`) // a: 5; b: 7

Nossos resultados mostram que mesmo que b seja “derivado” de a , alterar o valor de b não afeta o valor de a . Isso decorre do fato de que quando o mecanismo JavaScript executa a instrução b = a , ele cria um novo local de memória separado, coloca 5 nele e aponta b nesse local.

E os objetos? Considere o código abaixo.

 let c = { name: 'some name'} let d = c; console.log(`c: ${JSON.stringify(c)}; d: ${JSON.stringify(d)}`) // {"name":"some name"}; d: {"name":"some name"} d.name = 'new name' console.log(`c: ${JSON.stringify(c)}; d: ${JSON.stringify(d)}`) // {"name":"new name"}; d: {"name":"new name"}

Podemos ver que alterar a propriedade name via variável d também a altera em c . Isso decorre do fato de que quando o mecanismo JavaScript executa a instrução c = { name: 'some name ' } , o mecanismo JavaScript cria um espaço na memória, coloca o objeto dentro dele e aponta c para ele. Então, quando ele executa a instrução d = c , o mecanismo JavaScript apenas aponta d para o mesmo local. Ele não cria um novo local de memória. Assim, qualquer alteração nos itens em d é implicitamente uma operação nos itens em c . Sem muito esforço, podemos ver por que isso é um problema em formação.

Imagine que você esteja desenvolvendo um aplicativo React e em algum lugar você deseja mostrar o nome do usuário como some name lendo a variável c . Mas em algum outro lugar você introduziu um bug em seu código manipulando o objeto d . Isso faria com que o nome do usuário aparecesse como new name . Se c e d fossem primitivos não teríamos esse problema. Mas as primitivas são muito simples para os tipos de estado que uma aplicação React típica precisa manter.

Trata-se das principais razões pelas quais é importante manter um estado imutável em seu aplicativo. Recomendo que você verifique algumas outras considerações lendo esta breve seção do README do Immutable.js: o caso da imutabilidade.

Tendo entendido por que precisamos de imutabilidade em um aplicativo React, vamos agora dar uma olhada em como o Immer aborda o problema com sua função de produce .

Função de produce do Immer

A API principal do Immer é muito pequena, e a função principal com a qual você trabalhará é a função de produce . produce simplesmente recebe um estado inicial e um retorno de chamada que define como o estado deve ser alterado. O próprio retorno de chamada recebe uma cópia de rascunho (idêntica, mas ainda assim uma cópia) do estado para o qual faz toda a atualização pretendida. Finalmente, ele produce um novo estado imutável com todas as alterações aplicadas.

O padrão geral para esse tipo de atualização de estado é:

 // produce signature produce(state, callback) => nextState

Vamos ver como isso funciona na prática.

 import produce from 'immer' const initState = { pets: ['dog', 'cat'], packages: [ { name: 'react', installed: true }, { name: 'redux', installed: true }, ], } // to add a new package const newPackage = { name: 'immer', installed: false } const nextState = produce(initState, draft => { draft.packages.push(newPackage) })

No código acima, simplesmente passamos o estado inicial e um retorno de chamada que especifica como queremos que as mutações aconteçam. É simples assim. Não precisamos tocar em nenhuma outra parte do estado. Ele deixa initState intocado e compartilha estruturalmente as partes do estado que não tocamos entre os estados inicial e os novos. Uma dessas partes em nosso estado é a matriz de pets de estimação. O nextState produce uma árvore de estado imutável que contém as alterações que fizemos, bem como as partes que não modificamos.

Armado com esse conhecimento simples, mas útil, vamos dar uma olhada em como o produce pode nos ajudar a simplificar nossos redutores React.

Redutores de escrita com imersão

Suponha que temos o objeto de estado definido abaixo

 const initState = { pets: ['dog', 'cat'], packages: [ { name: 'react', installed: true }, { name: 'redux', installed: true }, ], };

E queríamos adicionar um novo objeto e, em uma etapa subsequente, definir sua chave installed como true

 const newPackage = { name: 'immer', installed: false };

Se fôssemos fazer isso da maneira usual com a sintaxe de propagação de array e objeto JavaScripts, nosso redutor de estado poderia se parecer com o abaixo.

 const updateReducer = (state = initState, action) => { switch (action.type) { case 'ADD_PACKAGE': return { ...state, packages: [...state.packages, action.package], }; case 'UPDATE_INSTALLED': return { ...state, packages: state.packages.map(pack => pack.name === action.name ? { ...pack, installed: action.installed } : pack ), }; default: return state; } };

Podemos ver que isso é desnecessariamente detalhado e propenso a erros para esse objeto de estado relativamente simples. Também temos que tocar em todas as partes do estado, o que é desnecessário. Vamos ver como podemos simplificar isso com Immer.

 const updateReducerWithProduce = (state = initState, action) => produce(state, draft => { switch (action.type) { case 'ADD_PACKAGE': draft.packages.push(action.package); break; case 'UPDATE_INSTALLED': { const package = draft.packages.filter(p => p.name === action.name)[0]; if (package) package.installed = action.installed; break; } default: break; } });

 //curried produce signature produce(callback) => (state) => nextState

 const curriedProduce = produce((draft, action) => { switch (action.type) { case 'ADD_PACKAGE': draft.packages.push(action.package); break; case 'SET_INSTALLED': { const package = draft.packages.filter(p => p.name === action.name)[0]; if (package) package.installed = action.installed; break; } default: break; } });

 // add a new package to the starting state const nextState = curriedProduce(initState, { type: 'ADD_PACKAGE', package: newPackage, }); // update an item in the recently produced state const nextState2 = curriedProduce(nextState, { type: 'SET_INSTALLED', name: 'immer', installed: true, });

 yarn add immer use-immer

 import React from "react"; import { useImmer } from "use-immer"; const initState = {} const [ data, updateData ] = useImmer(initState)

 // make changes to data updateData(draft => { // modify the draft as much as you want. })

 import React from "react"; import { useImmerReducer } from "use-immer"; const initState = {} const reducer = (draft, action) => { switch(action.type) { default: break; } } const [data, dataDispatch] = useImmerReducer(reducer, initState);