M3#A41 - function createReducer & tests

[SallesCosta]

Salve mestre @fdaciuk, observei que o retorno da função createReducer depende exclusivamente da existência da prop action.type em handleActions. Isso deveria fazer quebrar o teste abaixo:

pois o teste verifica o before. Isso fica mais evidente se eu passar um objeto para action como na foto a seguir:

Pergunto pois durante o desenvolvimento do TodoList eu coloquei um objeto.type no lugar do {}, aí meu teste quebrou e ao debugar eu percebi isso que citei e essa lógica não fez sentido pra mim. Será que estou deixando passar alguma coisa?

Grato!

@fdaciuk

[SallesCosta]

o teste está aqui

[fdaciuk]

Fala @SallesCosta! Você está certo em partes, mas vamos lá que eu vou explicar tudo =)

O teste que você fez, adicionando dados na action (especificamente o type) vai quebrar mesmo, e isso independe do uso do createReducer.

E pra entender o motivo, nós precisamos voltar lá para as primeiras aulas do módulo, onde eu expliquei como funciona o createStore e os reducers:

Todo reducer espera sempre como input um valor do estado, e uma action (objeto com a propriedade type).

Se o estado não for passado (igual a undefined), o valor que essa variável de estado recebe é o initialState definido para aquele reducer, correto?

Seria algo assim:

function counterReducer (state = 0, action) {
  return state
}

No caso do exemplo acima, se state for undefined, o valor de state dentro da função nunca será undefined, e sim zero.

E assim que uma action é passada, e o seu type é um type esperado pelo reducer, o reducer vai retornar a lógica com base naquele type:

function counterReducer (state = 0, action) {
  if (action.type === 'INCREMENT') {
    return state + 1
  }
  return state
}

Então aqui está a explicação do porquê o seu teste quebra: como você passou uma action válida, essa action foi executada pelo reducer, independente do valor anterior do estado, e o reducer vai retornar o novo valor do estado, não mais o initialState, que é o que o seu teste espera.

Passar o estado em before como undefined só vai acontecer em um momento, e nunca isso vai ser feito manualmente por você: quem faz isso é o Redux!

Lembra da aula onde falamos sobre o createStore? Nessa linha aqui é onde acontece o dispatch do estado inicial vazio (undefined) e nenhuma action válida é usada, só pro Redux já iniciar a store com todos os estados "prontos", apontando para o estado inicial de cada reducer.

Esse é o único momento em que uma action vai ser disparada sem o type, e o estado inicial vai ser undefined.

É esse cenário que nós estamos testando ali no primeiro print que você mandou: eu só coloquei o estado inicial como undefined, pois é assim que o Redux vai fazer o primeiro dispatch.

Dessa forma, o teste fica declarativo o suficiente pra dar a entender que, quando o estado inicial for undefined e nenhuma action for passada, significa que esse é o primeiro dispatch feito pelo Redux, que vai fazer o nosso estado se tornar o estado inicial.

Eu poderia ter passado qualquer coisa no before, mas aí eu não estaria simulando exatamente o que o Redux faz =)

Ficou mais claro?

[SallesCosta]

Entendi.. um pouco sofisticado para uma primeira leitura.. mas ao reler eu entendi. Ficou mais claro. Obrigado!

[fdaciuk]

Boa, perfeito! Se algo não ficou muito claro, ou se vc tiver qualquer outra dúvida, fique à vontade pra mandar aqui :D

[SallesCosta]

Aproveito a Issue M3#A41 pois o Lint está me bloqueando o create-reducer.ts para o commit. Pra subir pro repo eu comentei a parte correta e deixei visível a parte errada

Estou usando Ts.. então tem bastante any espalhado aí no projeto. De que forma eu posso contornar essa questão do hasOwnProperty?

Obrigado!

[fdaciuk]

Nesse caso você pode usar o Object.hasOwn no lugar do hasOwnProperty.

Só substituir:

handleActions.hasOwnProperty(action.type)

por:

Object.hasOwn(handleActions, action.type)

[SallesCosta]

Deu certo! Muito Obrigado!