<p>dva 2.0</p>

Que tal suporte nativo para ts?

Ao remover a modelagem, você considera apoiar a passagem de um redutor para destruir dados de estado não utilizados? https://github.com/dvajs/dva/issues/769

Que tal dva-cli renomeado para roadhog? Para que o conceito não seja confuso.

Pessoalmente, não concordo com o suporte nativo para ts. O framework deve tentar desvinculá-lo de outras pilhas de tecnologia não relacionadas, mantê-lo puro e, em vez disso, fazer menos. Por exemplo, o problema de estado do modelo de desmontagem também pode ser feito com o api existente e react-router O plano é dividir em componentes independentes, como react-router-dva. Também posso escrever react-navigation-dva para rn.

Existem também esquemas de otimização que também podem ser suportados na forma de plug-ins, como dva.use(reselect) , assim como o mecanismo de middleware expresso, apenas plug-ins estáticos são integrados e os outros são suportados separadamente , e até mesmo saga podem estar disponíveis. Escolhido

@nihgwu Eu estava errado, o que significa que, como o antd, ele é escrito em ts e não restringe os usuários.Isso tem a vantagem de não ter que sincronizar manualmente e publicar arquivos do tipo o tempo todo.

Concordo com a solução de plug-in, é possível fazer isso:

view - dva-core - [插件]

Entre eles, a parte igual ao dva atual é:

• dva-core
• dva-saga
• roteador

Os dois últimos são plug-ins.

O dva pode ser posicionado como uma biblioteca que se concentra em expressar a relação entre visualizações e dados? Que tipo de estrutura é a visualização e de que método é a fonte de dados, todos substituíveis? Então, a fim de atualizar suavemente para 1.0, defina dva como a combinação padrão de dva-core e saga?

Não sei se o encapsulamento subjacente é conveniente para suportar o tipo de despacho do tipo de instância.

dispatch({
  type: model => model.product.loadAll,
})

Memorizar string também é problemático e muitas vezes se esquece de escrever namespace, se houver um prompt suspenso, também é conveniente reconstruir ~

Não sei se é possível fornecer um conjunto de redutores por padrão para todos os dados do estado
Na maioria dos cenários, preciso escrever manualmente um redutor, que pode apenas atribuir um valor a um campo, portanto, se eu puder fornecer um método de conjunto de campo único pronto para mim por padrão, seria muito bom.

Os redutores podem ser implementados como uma árvore? Como agora, a divisão ns é forçada a nivelar a lógica. Um modelo corresponde à raiz de um redutor e há muitos redutores pendurados abaixo.

@xufei Acho que a saga deve estar no núcleo, e não é o

@xufei desculpe, também achei que você deveria estar se referindo a escrever em ts, mas não acho que seja necessário. Afinal, a interface de dva também é simples e não pode ser reescrita com ts por causa de digite arquivos.

@sorrycc Separating saga Também dou um

O Immutable.js pode ser compatível?

Suporte Immutable.js, Immutable.js tem um papel proeminente na otimização de desempenho

O empacotamento do Roadhog consome muito desempenho. Veja se você pode otimizá-lo. Se puder, otimize-o o máximo possível. Agora você precisa interromper outros contêineres antes que o servidor crie o projeto, caso contrário, o servidor ficará travado.

Immutable.js está obsoleto. Combinar as operações de lodash e propagação também pode obter efeitos imutáveis. E o lodash é basicamente embutido.

Na verdade, a experiência de desenvolvimento de dva 1.x já é muito boa, semelhante ao suporte de Immutable.js, saga de divisão, suporte nativo ts, parece desnecessário, todos pertencem ao amor próprio do desenvolvedor e não é muito para a eficiência e experiência de desenvolvimento real.

Pessoalmente, existem 4 pontos que precisam ser considerados pelo dva 2.x:

1. A otimização da camada de serviço, se pode ser extraída para o modelo e empacotada de uma maneira unificada, basicamente não se preocupa com request e fornece tratamento de exceção de rede por padrão, e agora basicamente você precisa escrever request.js sozinho;

2. É o problema do retorno de chamada do efeito da camada de visão. É irreal (muito complicado) separar completamente a lógica de negócios em dados do modelo e processá-los no efeito, portanto, uma solução mais elegante é necessária nesta área.

3. É a construção das comunidades circundantes de dva. Presentemente, os tipos de andaimes são ricos em exemplos, mas é necessária mais construção. Parece que o objetivo é atingir o nível de recursos da própria comunidade angular ou reativa.

4. O aprimoramento das ferramentas de construção, desempenho, funções, etc. (atualmente simulado) ainda é um pouco problemático

Para mim, o que mais me preocupa é a separação de router . Acho que dva só precisa incluir redux + redux-saga . redux comunidade react-router e fetch pareça desnecessária, assim como a Immutable mencionada acima. Isso pertence à preferência do desenvolvedor. Como mantenedor, não deve estar inclinado. Para a preferência do desenvolvedor, pode ser suportado na forma de plug-ins. Há também o problema da camada de serviço. Se necessário , você pode escrever plugin sozinho, não deve ser incluído em dva-core

@nihgwu Qual é a finalidade de extrair roteadores?

@nikogu fez muito, e os novatos ficarão perdidos, não sabem qual é o princípio.Mas se o documento for detalhado, também é possível

Qual é o propósito de remover o roteador

@nikogu

No momento, o escopo de aplicação do dva é um pouco estreito e está fortemente vinculado à comunidade react, incluindo naturalmente o view, e também fortemente vinculado ao react-router. Mas depois de usá-lo, descobri que alguns lugares não precisam de roteador, como aplicativos sem fio de várias páginas; alguns lugares reac-roteador não é aplicável, como react-nativo; alguns lugares não precisam reagir, como o nó , elétron e miniaplicativos.

Acho que dva pode fazer mais.

@nikogu se afasta do roteador porque podemos ter roteadores diferentes. Por exemplo, em RN, posso usar a navegação

Eu entendo que dva organiza redux e código saga e lógica em uma nova forma, em vez de fornecer um conjunto completo de estruturas de desenvolvimento web, como express, que também usa a API existente do node para fornecer as funções básicas do servidor web. você lida com corpo, cookie e qual mecanismo de template você escolhe pode ser customizado através de middleware

Se você gosta de uma solução completa, pode implementar dva-ant = dva-core + dva-plugins seu próprio uso

A combinação de dva deve ser a combinação de redux e saga, porque esses dois são o núcleo do fluxo de estado de dados, e os outros só podem ser considerados como periféricos construídos em dados e podem ser suportados por plug-ins ou outros métodos. Podemos comparar Express e Django, a diferença típica entre fazer menos e fazer mais, algumas pessoas gostam de grande e completo, mas a comunidade js respeita o pequeno mas bonito

Quanto a usar redux diretamente, a principal razão de eu usar dva é porque dva pode simplificar a estrutura de código e lógica de redux e melhorar a eficiência de produção.Este é também o núcleo do dva baseado em redux.

Se fizermos mais cegamente, os cenários de aplicação de dva se tornarão cada vez mais estreitos. Por exemplo, react-router não pode ser usado em RN (v4 já é compatível, mas é muito básico), RN também vem com fetch e há outras ligações fortes . A biblioteca também causará problemas de dependência de atualização. Ela ainda é react-router. V4 suporta RN, mas dva ainda é V2. Temos que esperar que dva atualize react-router antes de poder ser usado. Se for um plug- em e atualizar de forma independente, não haverá tal problema. NS

O que quero dizer com dva-core acima é tratar o pequeno núcleo como dva-core, pegar roteadores e similares neste, e então desenvolver alguns esquemas de integração padrão, como a versão unificada interna da empresa, para o middle e back office , e para H5, para pequenos programas, renderização do lado do servidor, etc.

2:00:
1. No desenvolvimento real, a lógica de negócios é implementada no modelo e o arquivo é muito grande.Qual é a relação entre o outro e o serviço? O serviço ou a solicitação podem ser integrados
2. Altere o roteador de reação para o próprio plug-in do sistema, ou qualquer outro, o objetivo é liberar a dependência

Quando 2.0 começará?

A solução SSR plugável abstrai o gerenciamento do roteador. O lado do servidor pode assumir a primeira solicitação de roteamento e usar o dva () compartilhado para inicializar a árvore de estado. Parece que, conforme o dva continua a atualizar, a renderização do servidor é fraca em a aplicação de novos recursos.

TypeScript e RN.Espero obter um suporte melhor

Pense em outro, forneça um padrão namespace

No processo de uso de dva, sempre haverá casos em que reducer não requer nenhum prefixo e a implementação atual de dva deve fornecer namespace , então eu tenho uma proposta, se namespace é default (ou global , * ), pensamos que model sob reducers é sem prefixo

Pessoalmente, pense em alguns pontos:

• Não depende de redux-saga , então você pode adicionar facilmente alguns recursos (como suporte assíncrono / espera)
• Dividido em vários pequenos módulos (por exemplo, uma única loja, um único roteador)
• Modelo aninhado de suporte

Recentemente modelamos vuex base em redux escrevemos um ponto de referência: https://github.com/d-band/yax

Recomenda-se que o servidor possa ser renderizado no lado do servidor, e as extremidades frontal e posterior podem ser gravadas juntas!

Posso definir o nome do diretório de rotas? Por exemplo, use container
Na verdade, quero dividir o catálogo por função, colocando modelo, serviço e contêiner juntos, caso contrário, o salto para vários catálogos destruirá o fluxo do coração. Para saber o que é o user.js aberto na aba acima do sublime, já o chamei assim: user.jsx, user.model.js, user.service.js. Junte user / model.js, service.js, container.js

Organizações de diretório como @zheeeng agora são suportadas e dva não tem restrições na organização de diretório.

@xufei
@sorrycc

Ao remover a modelagem, você considera apoiar a passagem de um redutor para destruir dados de estado não utilizados?

O controle manual é muito problemático, é recomendado implementar diretamente um conjunto de GC

Atualize pathToRegexp, seus métodos de análise e compilação não podem ser usados ​​diretamente

O acordo é melhor do que a configuração, reduzindo o acoplamento com outros projetos ou pilhas de tecnologia.

O negócio de efeitos é muito pesado e a ideia de estender o modelo é muito boa

@nihgwu pessoalmente concorda que "o núcleo do

@sorrycc O

Eu espero fortemente que dva-cli possa escolher gerar um padrão TypeScript

dva-core já pode ser usado em miniaplicativos WeChat

@yautah tentou? Você pode compartilhar o plano depois de experimentá-lo.

Eu sinto que dva-core só precisa fornecer redux encapsulamento de fluxo de dados, se os outros podem ser fornecidos na forma de plug-ins, ou seria melhor para os usuários escolhê-los, como esquemas de empacotamento e roteamento.

Espero apoiar dva-cli para apoiar a caneta

Suporte não ssr.

Como configurar HRM, a escrita de API é relativamente pouco