Dva: Discussão: estrutura clichê do dva-cli

Se for apenas um template, acho melhor clicar em todos, é fácil deletar mais, mas não é fácil adicionar se não tiver =. -,Meu conselho:

• simular 数据mock的接口文件
• src 项目源码目录
  
  
  
  • componentes 项目组件，一般为Stateless Components(Presentation Components)
  
  
  • recipientes 业务容器，一般为Smart Components，跟数据相关联
  
  
  • esquemas 业务通用布局
  
  
  • rotas 路由配置
  
  
  • serviços 项目数据接口
  
  
  • entradas 项目入口文件
  
  
  • [seletor] 可选，项目统一缓存数据
  
  
  • [constantes] 可选，项目统一常量
  
  
• pacote.json 项目信息
• proxy.config.js 数据mock配置信息
• webpack.config.js

Algumas coisas são diferentes de antes:

1. Remova o diretório entries e coloque index.js diretamente na camada externa, pois o padrão é um aplicativo de página única
2. router.js retirado de /routes/ , /routes/ contém apenas Route Component, não misturado, consulte emberjs

Ah, a demo do antd-init original segue essa estrutura?

@yiminghe você quer dizer que a demonstração do antd-init também tem essa estrutura? Não é um modo minimalista com apenas um arquivo index.js ?

Não parecia problema. Apenas um ponto, devemos recomendar a notação de containers?

Pessoalmente, acho que o componente de rota é um pouco ambíguo. Embora os contêineres pareçam ter um estilo baixo, seu significado é bastante claro (para aplicações de grande escala). Eu pessoalmente acho que o design de entradas e rotas pode ser considerado uma entrada para design em grande escala. Embora a api do dva e A ideia do design seja semelhante ao emberjs, mas o dva pode ser usado mais em aplicativos de grande escala no meio e no fundo no futuro, as aberturas que devem ser deixadas podem ser reservadas primeiro😄

O diretório de rotas atualmente é usado em nosso sistema para colocar 403, 404 e similares, todo sistema deveria ter.
Em segunda-feira, 25 de julho de 2016 às 22h11 niko [email protected] escreveu:

Eu pessoalmente acho rota
O componente é um pouco ambíguo. Embora os contêineres pareçam ter um estilo baixo, seu significado ainda é bastante claro (para aplicações de grande escala). Eu pessoalmente acho que o design de entradas e rotas pode ser considerado uma entrada para design de grande escala , embora a api e as ideias de design do dva sejam semelhantes ao emberjs. , mas talvez o dva seja mais usado em aplicações de grande escala no meio e fundo no futuro, as aberturas que devem ser deixadas podem ser deixadas primeiro😄

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dvajs/dva/issues/21#issuecomment -234964419, ou mudo
o segmento
https://github.com/notifications/unsubscribe-auth/AA2yaEP4a7dOBvvZH-V6b0xLOyEOjBm-ks5qZMQtgaJpZM4JT_1b
.

Obrigado pela discussão, deixe-me saber o meu entendimento.

rotas x contêineres

As rotas são usadas para armazenar os componentes definidos pelo roteador, correspondentes ao roteador , que podem ser containers ou componentes. Outra razão para iniciar um diretório de rotas separado é considerar a função geradora de multa de acompanhamento, como dva generate route users , gerar routes/Users.jsx é containers/Users.jsx de entender do que

Além disso, a camada externa possui um router.js para configurar as informações de roteamento. (Observe a diferença entre roteador e rota)

pasta containers ou não

Ou seja: você recomenda a forma como o container é escrito? Eu não recomendo primeiro, 1 é que containers fácil de ser confundido com routes , e 2 é reduzir o conceito. Os componentes contêm contêiner e componente, assim como

você quer a pasta de layouts

Eu também tenho uma pasta de layout antes. Ontem, Chen Yu disse que os layouts são na verdade componentes, então por que eles deveriam ser separados? Eu acho que o mesmo é verdade, então eu deletei os layouts e coloquei o nome nos componentes com o sufixo do layout.

pastas seletores e constantes

Isso deve ser organizado sob o modelo.

pasta de entradas

Isso realmente depende de que tipo de aplicativos são a maioria de nós: várias páginas ou uma única página. Eu acho que 80% deveria ser um aplicativo de página única, então eu coloquei index.js e simplifiquei o conceito de entradas. Os aplicativos de várias páginas são fornecidos por meio de documentação ou complemento. Além disso, a julgar pelos aplicativos de várias páginas (subaplicativos) que fiz antes, a organização é realmente bastante complicada. Pode ser necessário que cada página (subaplicativo) tenha seus próprios modelos, componentes e serviços, mas não é necessário ter um diretório de entradas.Pode resolver o problema, acho que seria melhor aconselhar através de documentação ou outros meios.

É a demonstração do antd-init redux

Acontece que as rotas se referem ao Componente correspondente à rota, então isso não é problema.Do fundo angular, está muito acostumado a cada rota ter um modelo e controlador correspondente, o que é um pouco semelhante a esse conceito.

@yiminghe antd-init mantém a versão de demonstração mínima e inicializa no dva-cli.

Na verdade, ainda concordo com a estrutura dada por @nikogu .

Meu hábito anterior é container + component (container é usado quando connect é usado, e component é usado quando connect não é usado) A rota contém apenas o conteúdo do roteador, ou seja, a estrutura de roteamento. Então eu ainda quero manter o recipiente.

Seja neutro quanto a manter ou não a entrada, e prefira mantê-la, afinal, para uma aplicação de página única, mais uma entrada não terá nenhum efeito.

A pasta de constantes já foi usada antes, mas não é usada, não é recomendada.

Embora os layouts também sejam um componente, do ponto de vista da engenharia, a entrada do componente de layout estável torna o projeto mais fácil de usar. Caso contrário, talvez eu nem saiba que os layouts são colocados em componentes.

Existem também testes (testes), estáticos (arquivos estáticos), estilos (estilos globais), utils (métodos gerais de ferramentas). Esses diretórios também podem ser considerados.

Além disso, os dados simulados agora são colocados no arquivo proxy.config.js? Que tal fazer um diretório simulado?

diretório de testes +1

@afc163 O diretório simulado está fora, proxy.config.js pode configurar para simular ou redirecionar para outros endereços

mudança:

1. Agora existe um diretório simulado, na camada externa
2. testes plus, baseado na implementação de uma ferramenta-teste-mocha
3. utils também é adicionado, coloque services/xFetch aqui para tornar os serviços mais puros
4. index.less é o estilo global, substitua por style.less?Eu sinto que o estilo global não precisa de uma pasta, certo?

de outros:

1. Sem adicionar layouts e estáticos, a pasta é muito melhor. .Eu olhei através de outros clichês e basicamente não forneci esse tipo de
2. Eu ainda insisto em juntar containers com componentes, eles eram separados antes, mas descobri que extrair um arquivo com o mesmo nome dos componentes para conectar é muito trabalhoso, principalmente depois que há muitos arquivos dentro dos containers.Parece desmontar por desmontar, sou mais pragmático

Minha sugestão é dividir em containers e components pelos seguintes motivos:

Primeiro, introduza um artigo Componentes de apresentação e contêiner ,

Containers não são componentes puros em termos de design de arquitetura de projeto. Claro, ele tem as características de componentes ao mesmo tempo, mas desempenha um papel como um container para dados associados e fornece a função de processamento de dados. modelo de dados é o modelo, e os Componentes não precisam se preocupar com o modelo, e a implementação nele não será vinculada ao modelo, nem será despachada. Simplificando, acho que a implementação dos componentes é a mesma dos componentes da antd, com uma responsabilidade única e focada, independente do framework.

Portanto, a função mais óbvia de distinguir contêineres e componentes é permitir que os desenvolvedores do projeto usem 思维上对应用的组件进行划分 . Se apenas os componentes forem fornecidos, os dois tipos de componentes de Presentational and Container Components serão misturados, de modo que o efeito obtido é A diferença entre os dois não é óbvia, e é fácil misturá-los.

Esta situação como @sorrycc disse:

Descobri que é muito doloroso extrair um arquivo com o mesmo nome dos componentes para se conectar, especialmente depois que há muitos arquivos em contêineres

Essa situação pode ser evitada, por exemplo, um projeto que escrevi antes foi dividido assim:

O papel do container são todas as operações relacionadas ao modelo, e os componentes são componentes de apresentação puros.Se o subcomponente dos componentes de apresentação também estiver relacionado ao modelo, então este subcomponente será um container.

Resumindo, a distinção entre containers e componentes é mais para esclarecer o pensamento do desenvolvedor, o que tornará o link de dados mais claro.

“ Em uma versão anterior deste artigo, afirmei que os componentes de apresentação deveriam conter apenas outros componentes de apresentação. Já não acho que seja assim. Se um componente é um componente de apresentação ou um contêiner é o detalhe de sua implementação. Você deve poder substituir um componente de apresentação por um contêiner sem modificar nenhum dos sites de chamada. Portanto, os componentes de apresentação e contêiner podem conter outros componentes de apresentação ou contêiner muito bem ”

看到最后，我感觉作者好像在说“ Cabe a você. ” :smirk: 。。。。然后我就更懵了

Este artigo está no ar há muito tempo e sinto que o ponto de vista do autor mudou, incluindo o f8app, que é uma mistura de contêineres e componentes.

Esta pergunta, @sorrycc, ou apenas siga a sua, não há grande problema, certifique-se:

.
├── /mock/
├── /src/
│ ├── /components/       # React components
│ ├── /models/           # model 信息
│ ├── /routes/           # 路由 Component
│ ├── /services/         # 处理和服务器的交互
│ ├── index.html
│ ├── index.js           # 应用入口
│ ├── index.less
│ └── router.js          # 路由配置
├── package.json
├── proxy.config.js
└── webpack.config.js

@nikogu Ok, vamos usar isso primeiro. Essa estrutura de diretório é inicializada com [email protected] .