Dva: Обсуждение: шаблонная структура dva-cli

Если это просто шаблон, я думаю, что лучше нажать все из них.Легко удалить больше, но не так просто добавить, если у вас его нет =. -,Мой совет:

• издеваться над 数据mock的接口文件
• источник 项目源码目录
  
  
  
  • компоненты 项目组件，一般为Stateless Components(Presentation Components)
  
  
  • контейнеры 业务容器，一般为Smart Components，跟数据相关联
  
  
  • макеты 业务通用布局
  
  
  • маршруты 路由配置
  
  
  • услуги 项目数据接口
  
  
  • записи 项目入口文件
  
  
  • [селектор] 可选，项目统一缓存数据
  
  
  • [константы] 可选，项目统一常量
  
  
• package.json 项目信息
• proxy.config.js 数据mock配置信息
• webpack.config.js

Несколько вещей отличаются от предыдущих:

1. Удалите каталог entries и поместите index.js непосредственно во внешний слой, потому что по умолчанию это одностраничное приложение.
2. router.js взято из /routes/ , /routes/ содержит только компонент маршрута, не смешанный, см. emberjs

О, следует ли демонстрация оригинального antd-init этой структуре?

@yiminghe, вы имеете в виду, что демо antd-init также имеет эту структуру?Разве это не минималистский режим только с одним файлом index.js ?

Посмотрел без проблем. Только один момент, должны ли мы рекомендовать нотацию контейнеров?

Лично мне маршрутная составляющая кажется немного двусмысленной.Хотя у контейнеров вроде низкий стиль,но смысл их вполне понятен(для крупномасштабных приложений).Я лично считаю,что оформление записей и маршрутов можно расценивать как запись для масштабного дизайна.Хотя апи dva и идея дизайна похожа на emberjs, но dva может использоваться больше в масштабных приложениях в середине и на заднем плане в будущем, отверстия, которые должны быть оставлены, могут быть зарезервированы в первую очередь😄

В настоящее время в нашей системе используется каталог маршрутов для проставления 403, 404 и т. д. Он должен быть в каждой системе.
Пн, 25 июл 2016 в 10:11 вечера Niko [email protected] писал:

Я лично думаю, что маршрут
Компонент немного двусмысленный.Хотя контейнеры кажутся низким стилем, их смысл все же достаточно ясен (для масштабных приложений).Я лично считаю, что оформление входов и маршрутов можно расценивать как запись для крупномасштабного дизайна , хотя апи и дизайнерские задумки dva похожи на emberjs. , но возможно dva будет использоваться больше в масштабных приложениях в середине и фоне в будущем, те щели, которые должны быть оставлены, можно оставить в первую очередь😄

—
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/dvajs/dva/issues/21#issuecomment -234964419 или отключить звук
нить
https://github.com/notifications/unsubscribe-auth/AA2yaEP4a7dOBvvZH-V6b0xLOyEOjBm-ks5qZMQtgaJpZM4JT_1b
.

Спасибо за обсуждение, дайте мне знать мое понимание.

маршруты против контейнеров

Маршруты используются для хранения компонентов, определенных маршрутизатором, соответствующих маршрутизатору , которые могут быть контейнерами или компонентами. Еще одна причина для запуска отдельного каталога маршрутов заключается в том, чтобы рассмотреть последующую функцию точного генератора, такую ​​​​как dva generate route users , создание routes/Users.jsx containers/Users.jsx для понимания, чем

Кроме того, на внешнем уровне есть router.js для настройки информации о маршрутизации. (Обратите внимание на разницу между маршрутизатором и маршрутом)

папка контейнеров или нет

То есть: вы рекомендуете, как написан контейнер? Во-первых, я не рекомендую это делать, во-первых, containers легко спутать с routes , а во-вторых, уменьшить концепцию. Компоненты содержат как контейнер, так и компонент, так же как и

тебе нужна папка layouts

У меня тоже раньше была папка макетов.Вчера Чен Ю сказал,что макеты на самом деле компоненты,так зачем их разделять?Я думаю то же самое верно,поэтому я удалил макеты и поставил название в компонентах с суффиксом макета.

папки селекторов и констант

Это должно быть организовано в соответствии с моделью.

папка записей

На самом деле это зависит от того, какой тип приложений у большинства из нас — многостраничный или одностраничный. Думаю 80% должно быть одностраничным приложением, поэтому выдвигаю index.js и упрощаю концепцию записей. Многостраничные приложения предоставляются через документацию или дополнение. Кроме того, судя по многостраничным (суб-приложениям) приложениям, которые я делал ранее, организация на самом деле достаточно сложная, может быть необходимо, чтобы для каждой страницы (суб-приложения) были свои модели, компоненты и сервисы, но не обязательно иметь каталог записей.Может решить проблему, чувствую, было бы лучше дать совет через документацию или другие средства.

Это демо antd-init redux

Получается, что маршруты относятся к компоненту, соответствующему маршруту, так что это не проблема.С точки зрения ангуляра очень привычно, чтобы каждый маршрут имел соответствующий шаблон и контроллер, что чем-то похоже на эту концепцию.

@yiminghe antd-init сохраняет минимальную демо-версию, а затем загружается в dva-cli.

На самом деле, я все еще согласен со структурой, данной @nikogu .

Моя предыдущая привычка — контейнер + компонент (контейнер используется, когда используется соединение, а компонент используется, когда соединение не используется) Маршрут содержит только содержимое маршрутизатора, то есть структуру маршрутизации. Так что я все еще хочу сохранить контейнер.

Относитесь нейтрально к тому, сохранять ли запись или нет, и предпочитайте ее сохранять, ведь для одностраничного приложения еще одна запись не будет иметь никакого эффекта.

Папка с константами использовалась и раньше, но не используется вообще, не рекомендуется.

Хотя макеты также являются компонентом, с инженерной точки зрения запись компонента стабильного макета упрощает использование проекта. Иначе я могу даже не знать, что макеты размещаются под компонентами.

Еще есть тесты (тесты), static (статические файлы), styles (глобальные стили), utils (общие методы инструмента) Эти директории тоже можно рассматривать.

Кроме того, фиктивные данные теперь помещаются в файл proxy.config.js? Как насчет создания фиктивного каталога?

каталог тестов +1

@afc163 afc163 Макетный каталог находится снаружи, proxy.config.js может настроить, следует ли имитировать или перенаправлять на другие адреса.

изменять:

1. Теперь есть фиктивный каталог во внешнем слое
2. тесты плюс, основанные на реализации atool-test-mocha
3. также добавлены утилиты, поместите здесь services/xFetch чтобы сделать сервисы более чистыми
4. index.less - это глобальный стиль, замените его на style.less? Я чувствую, что глобальному стилю не нужна папка, верно?

разное:

1. Без добавления макетов и статики папка намного лучше. .Я просмотрел другие шаблоны и в основном не предоставлял такого рода
2. Я по-прежнему настаиваю на том, чтобы ставить контейнеры вместе с компонентами, раньше они были разделены, но я обнаружил, что извлечение файла с тем же именем, что и компоненты, для подключения очень болезненно, особенно после того, как в контейнерах слишком много файлов.Такое ощущение, что разборка ради разборки, я более прагматичен

Я предлагаю разделить на containers и components по следующим причинам:

Сначала представьте статью Presentational and Container Components ,

Контейнеры не являются чистыми компонентами с точки зрения проектирования архитектуры проекта.Конечно, они одновременно обладают характеристиками компонентов, но играют роль контейнера для ассоциированных данных и обеспечивают функцию обработки данных. модель данных - это модель, а компонентам не нужно заботиться о модели, и реализация в ней не будет связана с моделью, и не будет диспетчеризации.Проще говоря, я думаю, что реализация компонентов такая же, как и компоненты of antd, с единой и целенаправленной ответственностью, независимой от структуры.

Таким образом, наиболее очевидная функция различения контейнеров и компонентов — позволить разработчикам проекта использовать 思维上对应用的组件进行划分 Если предоставлены только компоненты, то два типа компонентов Presentational and Container Components будут смешаны вместе, так что достигнутый эффект: разница между ними не очевидна, и их легко смешивать.

Эта ситуация, как сказал @sorrycc :

Я обнаружил, что очень больно извлекать файл с тем же именем, что и компоненты, чтобы подключиться, особенно после того, как в контейнерах много файлов.

Этой ситуации можно избежать, например, проект, который я писал ранее, был разбит так:

Роль контейнера - все операции, связанные с моделью, а компоненты - чисто презентационные компоненты.Если подкомпонент презентационных компонентов также связан с моделью, то этот подкомпонент будет контейнером.

Подводя итог, различие между контейнерами и компонентами больше для того, чтобы прояснить мышление разработчика, что сделает связь с данными более понятной.

«В более ранней версии этой статьи я утверждал, что презентационные компоненты должны содержать только другие презентационные компоненты. Я больше не думаю, что это так. Является ли компонент презентационным компонентом или контейнером, это деталь его реализации. Вы должны иметь возможность заменить презентационный компонент контейнером, не изменяя ни одного из сайтов вызовов. Следовательно, и презентационные, и контейнерные компоненты могут прекрасно содержать другие презентационные или контейнерные компоненты».

看到最后，我感觉作者好像在说“ Вам решать. :smirk: 。。。。然后我就更懵了

Эта статья вышла давно, и я чувствую, что точка зрения автора изменилась, в том числе и их f8app, представляющий собой смесь контейнеров и компонентов.

Этот вопрос, @sorrycc, или просто следуйте за вашим, нет большой проблемы, убедитесь:

.
├── /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 Хорошо, давайте сначала воспользуемся этим. Эта структура каталогов инициализируется с помощью [email protected] .