Redux: Proposta: Renomear "lojas" para "redutores"

-1 a curva de aprendizado neste repo já parece íngreme. Não vamos torná-lo ainda mais íngreme introduzindo uma nova terminologia para novos usuários de fluxo.

Internamente, eles podem ser chamados de redutores, mantenha-os publicamente como depósitos para que seja mais fácil de grocar.

Sinceramente, acho mais confuso do jeito que está agora. Totalmente anedótico, mas várias pessoas IRL ficaram confusas pensando em como uma "loja" poderia ser sem estado.

As principais características das "lojas" no Flux tradicional são que elas 1) mantêm o estado e 2) emitem eventos de mudança. Nenhum dos quais é verdade no Redux.

Concordo que precisamos esclarecer a terminologia e, em alguns casos, encontrar uma nomenclatura melhor.
Acho que, como primeiro passo, deve haver algum JSDoc, então uma seção de terminologia também ajudaria.
Em geral, temos que manter um certo nível de consistência.

Eu me pergunto se existe um termo que não soa como FP, mas também não é uma “loja”.
Domínios?

O OTOH já é chamado de Redux, então pelo menos “redutor” soa relacionado.

Que tal "atualizações de etapas" ou "steppers", que movem seu estado um passo à frente. Já vi isso sendo usado na literatura do Elm, tendo uma função chamada step , update ou next

Os domínios contêm bagagem do node.js.

Eles não são armazenamentos de como funcionam, mas você ainda coloca sua lógica de estado lá, como os armazenamentos de fluxo. Eles são gerentes estaduais, como os depósitos de fluxo deveriam ser.

Redutores são bons se você estiver interessado em mudar seu nome.

Especialmente porque "redutor" é uma descrição precisa do que eles realmente são :)

Updaters? Parece descritivo + menos esnobe do que redutores.

Também gosto de reducer

Acho que não vejo por que "redutor" é esnobe. Não é melhor usar o termo real do que inventar um novo que seja menos descritivo?

Eu acho que ambos podem ser válidos, e depende de qual ponto de vista você vê: um _redutor_ de ações (no estado) ou um _atualizador_ de estado.

"Updater" implica que é mutativo. "Redutor" deixa claro que você está retornando a um novo estado, não modificando o antigo.

Esse é um ponto forte a favor, eu acho, pode ajudar com o problema de redux não funcionar corretamente com mutações

Eu aprecio a necessidade de manter o Redux amigável para pessoas que não estão familiarizadas com FP, mas podemos resolver isso com uma documentação melhor. Eu gosto dos documentos atuais, mas à primeira vista eles são um pouco opressivos. Um bom site de documentação que priorize as coisas familiares (criadores de ações, lógica do redutor) sobre as coisas avançadas (middleware, recarregamento a quente) seria muito útil.

E ainda, a julgar pelo rápido crescimento do seguinte aqui, devemos estar fazendo algo certo :)

Estou aberto a mudar “Lojas” para “Redutores” se isso acontecer junto com documentos melhores.

O elemento essencial é preservar a vibração “é como o Flux, mas melhor, não se preocupe”. Não quero que as pessoas pensem que é semelhante ao Reflux ou algo assim, que soa como Flux, mas quebra algumas de suas propriedades legais. Eu também não quero que eles pensem que precisam aprender FP. Contanto que possamos mantê-lo assim, estou bem com essa mudança.

Sugestão sobre a qual tenho menos certeza: se renomearmos a classe Redux para Store (pense nisso: seus dois propósitos são manter o estado e emitir eventos de mudança), a API de nível superior se torna:

const store = createStore(reducers);

<Provider store={store} />

Isso comunica a ideia muito bem, eu acho. Os redutores são para onde vai a lógica da sua loja, mas não são as próprias lojas.

Eu gosto disso, embora store.dispatch pareça errado então.

Sim, essa é a única coisa que eu realmente não gosto, mas os outros métodos fazem sentido: store.getState() , store.setState() , store.subscribe()

Agora que penso nisso, não estamos realmente “despachando” nada.
Ugh, nomear é uma toca de coelho.

Ok, então o que temos até agora são:

• ação (criadores)
• (armazenar) redutor
• funções de middleware
• funções de retorno de chamada (ouvinte)
• algo que aciona a cadeia de chamadas de funções (chamada despachante)
• algo que mantém o estado mutável (com setters e getters)

Talvez possamos dar um passo para trás e repensar a nomenclatura?

Talvez store.dispatch não seja tão ruim. Podemos apenas explicar que em vez de muitas Lojas, temos uma única Loja, e você compõe a partir dos Redutores. Sem lojas = não há necessidade de um despachante separado, portanto dispatch está disponível diretamente na loja.

@gaearon eu concordo.

@emmenko Bom resumo. Qualquer divisão de terminologia deve distinguir entre _ criadores de ação_ e _ações_. Ele também deve distinguir entre a _dispatcher_ ou _estratégia de despacho_, que engloba middleware + redutores, bem como o método _dispatch_ que dispara um _ciclo de despacho_.

Vamos fazer isso:

• Renomear lojas para redutores
• Renomeie a "instância Redux" para Store de acordo com https://github.com/gaearon/redux/issues/137#issuecomment -113252359
• Explique que se você olhar para as tradicionais Flux Stores, verá Redutores presos nelas

Alguém quer liderar o esforço de novos documentos? Vai precisar de alguma estruturação: um glossário, um README, um tutorial simples de “começar a trabalhar” e talvez um guia de “decisões de design” mais aprofundado.

@gaearon Vou me oferecer como voluntário para liderar :) Já tenho um esboço iniciado.

Obrigado: +1:

Vou me oferecer para liderar isso

Obrigado! : +1:: +1:: +1:

Pessoalmente, como resultado final, eu realmente gostaria de ter um site gerado automaticamente com:

• começando
• tutoriais
• exemplos ao vivo

... e como um recurso interessante:

• documentação gerada a-la docco (por exemplo: como jasmine ) para que o código-fonte seja claramente explicado

Mas começar com markdown e jsdoc é, obviamente, o primeiro passo;)

Certo, acho que a primeira etapa é escrever os documentos no formato Markdown, então podemos portá-los para um site de documentos realmente bom. : +1: para JSDoc também. Vou fazer uma tentativa final em https://github.com/gaearon/redux/pull/87 esta noite, mas não tenho certeza se as anotações de fluxo valem a pena neste ponto, a menos que livremos a base de código da sobrecarga de funções. (Ou a menos que alguém me ensine como digitá-los corretamente sem que o Flow reclame.)

Acho que Flow não é uma prioridade do ATM.

+1 para lojas sendo chamadas de redutoras.

Não gosto de chamar essas coisas mais declarativas e sem estado de lojas.

Eu gosto das novas idéias de nomes. Eu também proponho renomear Connector para algo como Subscription . Connector é muito genérico e, embora eu saiba que ele está conectando o estado e o despachante do redux a seus filhos, acho que uma assinatura é uma descrição melhor do que está acontecendo. É um pouco complicado conseguir um despachante com sua assinatura, mas acho que está tudo bem.

-1 para lojas sendo chamadas de redutoras, como um nome não é muito intuitivo para novos usuários (pelo menos aqueles sem um fundo de programação funcional). Talvez Updater ou Transformer fosse melhor, ou Store Updater se quiséssemos ser mais explícitos sobre isso.

“Transformers” foram sugeridos algumas vezes. Não sugere natureza mutável como Updaters, é mais acessível que Reducers e não carrega a conotação de “armazenamento” de Stores.

Como você gosta de Transformers?

+1 para redutores

Conforme observado por @faassen no Twitter, um bom argumento para “redutores” é chamar de volta o nome do projeto. Temos a chance de dizer “Isso é como o Flux, mas há uma única Loja. Assim como você pode compor seu aplicativo em componentes React, no Redux, você compõe essa Loja a partir de Redutores. Eles são chamados de Redutores porque sua função de correspondência de assinatura foi passada para [].reduce() : (state, action) => state . Bla bla bla ”

propagação angular como um incêndio e usa palavras como

• diretriz
• isolar
• transcluir

Ignorar a programação, transformar e reduzir são coisas diferentes. Eu escolheria o nome mais preciso.

Se eles não armazenam dados, não os chame de lojas.

Você está mudando de uma forma para outra ou reduzindo de muitos valores para um?

Transformer => mapa
Redutor => reduzir

Parece reduzir para mim.

Também estou a favor de reducers ! : +1:

Inspire-se no Elm. https://github.com/evancz/elm-architecture-tutorial#the -basic-pattern

A melhor palavra seria update . Loja é um disparate, sempre foi "Modelo". Não há necessidade de reinventar a roda ou confundir as pessoas.

Meu problema em chamá-los de atualizadores é que as pessoas podem pensar que eles são mutativos. Se a nomenclatura pode ajudar a esclarecer a natureza não mutante, isso seria um grande bônus.

Você está mudando de uma forma para outra ou reduzindo de muitos valores para um?

Estou acumulando. “Como uma ação transforma um estado no próximo estado.” Conceitualmente, eles estão reduzindo muitas ações do estado inicial (indefinido), e a memoização é apenas uma otimização.

Transformador de estado

Tente evitar reinventar / redescobrir o máximo possível. As pessoas o chamam de reduce , scan , fold e update .

reducer parece ser preciso do ponto de vista do javascript ...
Não vejo o valor de nomeá-lo a partir de um conceito de outra linguagem, mesmo que seja mais preciso.

Não tenha uma posição firme sobre o que deve ser, mas IMO deve ser algo que representa com mais precisão o tipo de computação. Se for uma palavra umfaliar para a maioria dos programadores, isso pode ser compensado pela documentação.

@vramana não é um map , é um reduce , pois pega o state anteriormente acumulado e um novo action e retorna um novo state .

Se você tivesse uma matriz de todas as ações do seu aplicativo, usaria esta função para reduzi-lo ao estado final do aplicativo:

function reducer(state, action) {
  // switch (action.type) ...
  // return state;
}
const finalState = allAppActions.reduce(reducer, initialState);

Agora, o que você realmente tem é stream de actions no tempo, que é conceitualmente o mesmo que um array, mas no tempo (você pode reduzi-lo em stream de state s).

Gosto de pensar nisso como uma projeção (de um registro de eventos para uma estrutura de dados).
O pessoal do banco de dados costumava chamar isso de "visões materializadas".

Eu gosto de reduzir ou dobrar, é bem compreendido por diferentes comunidades

Eu prefiro muito mais Transformers a Redutores: é claro o que significa do uso normal da palavra em inglês.

Redutores.
Primeiro, é uma biblioteca javascript e javascript tem [].reduce(reducer, initialState) .
Em segundo lugar, Redu (cer) x já está no nome da biblioteca.
Terceiro, https://blog.javascripting.com/2015/06/19/flux-no-more-stores-meet-reducer/ , outras pessoas e bibliotecas usarão o termo 'redutores'.

O redutor é preciso e tem um precedente no vanilla JS. Não tenho certeza de como isso poderia ser melhorado.

Redutores então.

(Siga o progresso em # 140)

Ocasionalmente, encontro discussões antigas chamando-as de “lojas” e fico maravilhado com a forma como isso era ridiculamente confuso em retrospectiva.

"recipiente de estado"?

Sim, esta foi uma boa mudança :)