<p>dva 2.0</p>

Как насчет встроенной поддержки ts?

Рассматриваете ли вы при немоделировании поддержку передачи редуктора для уничтожения неиспользуемых данных состояния? https://github.com/dvajs/dva/issues/769

Как насчет того, чтобы два-кли переименовали в Турбосвина? Чтобы концепция не запуталась.

Лично я не согласен с встроенной поддержкой ts. Фреймворк должен попытаться отвязать его от других несвязанных технологических стеков, сохранить его в чистоте и, скорее, делать меньше. Например, проблема состояния модели размонтирования также может быть решена с помощью существующие api и react-router Планируется разделить на независимые компоненты, такие как react-router-dva. Я также могу написать response-navigation-dva для rn.

Существуют также схемы оптимизации, которые также могут поддерживаться в виде подключаемых модулей, например dva.use(reselect) , как и механизм промежуточного программного обеспечения Express, только статические подключаемые модули являются встроенными, а остальные поддерживаются отдельно. , и даже может быть доступна сага.

@nihgwu Я был неправ, что означает, что, как и antd, он написан на ts и не ограничивает пользователей. Преимущество этого заключается в том, что вам не нужно постоянно вручную синхронизировать и публиковать файлы типов.

Я согласен с решением надстройки, возможно ли это сделать:

view - dva-core - [插件]

Среди них часть, равная текущему два, это:

• два ядра
• два-сага
• маршрутизатор

Последние два - это плагины.

Можно ли позиционировать dva как библиотеку, которая фокусируется на выражении взаимосвязи между представлениями и данными? Какая структура представляет собой представление и какой метод является источником данных, и все это можно заменить? Затем, для плавного обновления до 1.0, определите dva как комбинацию dva-core и saga по умолчанию?

Я не знаю, удобна ли базовая инкапсуляция для поддержки типа отправки типа экземпляра?

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

Запоминание строки также проблематично, и часто забывают написать пространство имен, если есть раскрывающееся приглашение, также удобно восстановить ~

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

Можно ли реализовать редукторы в виде дерева? Как и сейчас, ns split вынужден сглаживать логику. Модель соответствует корню редуктора, а внизу висит слишком много редукторов.

@xufei Я думаю, что сага должна быть в ядре, а это не нынешнее

@xufei Мне очень жаль, я также почувствовал, что вы должны иметь в виду писать в ts, но я не думаю, что это необходимо. В конце концов, интерфейс dva также прост, и его нельзя переписать с помощью ts из-за тип файлов.

@sorrycc Separating saga Я также

Можно ли поддерживать Immutable.js?

Поддержка Immutable.js, Immutable.js играет важную роль в оптимизации производительности.

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

Immutable.js устарел. Комбинирование операций lodash и распространения также может дать неизменный эффект. И lodash в основном встроенный.

Фактически, опыт разработки dva 1.x уже очень хорош, как и поддержка Immutable.js, split saga, встроенная поддержка ts, это кажется ненужным, все принадлежит самолюбивым разработчикам, и это немного на фактическую эффективность разработки и опыт.

Лично dva 2.x должна учитывать 4 момента:

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

2. Это проблема обратного вызова эффекта уровня представления. Нереалистично (слишком громоздко) полностью разделить бизнес-логику на данные модели и обработать ее в эффекте, поэтому в этой области необходимо более элегантное решение.

3. Это строительство окружающих сообществ dva. В настоящее время типы строительных лесов изобилуют примерами, но требуется больше строительства. Похоже, что цель состоит в том, чтобы достичь уровня ресурсов самого angular или React сообщества.

4. Улучшение инструментов сборки, производительности, функций и т. Д. (В настоящее время макет) по-прежнему вызывает некоторые проблемы.

Меня больше всего беспокоит разделение router . Я думаю, что dva должно включать только redux + redux-saga . Сообщество redux выступает за то, чтобы делать как можно меньше, поэтому пакеты 1.x react-router и fetch кажутся ненужными, равно как и Immutable упомянутые выше. Это относится к предпочтениям разработчика. Как сопровождающий, к нему не следует склоняться. По желанию разработчика это может поддерживаться в виде плагинов. Также существует проблема уровня обслуживания. При необходимости , вы можете написать plugin самостоятельно, это не должно быть включено в dva-core

@nihgwu Какова цель извлечения маршрутизаторов?

@nikogu сделал слишком много, и новички будут в недоумении, не

С какой целью снимают роутер

@nikogu

В настоящее время сфера применения dva немного узка, и она сильно привязана к сообществу React, естественно, включая представление, а также сильно привязана к response-router. Но после его использования я обнаружил, что в некоторых местах маршрутизатор не нужен, например, в беспроводных многостраничных приложениях; в некоторых местах реактивный маршрутизатор неприменим, например, response-native; в некоторых местах реагировать не нужно, например, node , электрон и апплеты.

Я думаю, что два могут сделать больше.

@nikogu отрывается от роутера, потому что у нас могут быть разные роутеры. Например, в RN я могу использовать реакцию-навигацию, а реактивная навигация также поддерживает Интернет, который может полностью поддерживаться плагином для достижения лучшей настройки.

Я понимаю, что dva организует код и логику redux и saga в новой форме, а не предоставляет полный набор фреймворков веб-разработки, таких как express, который также использует существующий api узла для обеспечения основных функций веб-сервера. Что касается того, как вы имеете дело с телом, cookie и какой шаблонизатор вы выбираете, можно настроить с помощью промежуточного программного обеспечения

Если вам нравится полное решение, вы можете реализовать dva-ant = dva-core + dva-plugins собственного использования.

Комбинация dva должна быть комбинацией redux и saga, потому что эти два являются ядром потока состояний данных, а остальные могут рассматриваться только как периферийные устройства, построенные на данных, и могут поддерживаться плагинами или другими методами. Мы можем сравнить Express и Django, типичная разница между меньшим и большим делом, некоторым людям нравится большой и полный, но сообщество js уважает маленькие, но красивые.

Что касается прямого использования redux, основная причина, по которой я использую dva, заключается в том, что dva может упростить структуру кода и логику redux и повысить эффективность производства.Это также ядро ​​dva, основанное на redux.

Если мы слепо сделаем больше, сценарии приложений dva станут все уже и уже. Например, в RN нельзя использовать response-router (v4 уже поддерживает, но является очень простым), RN также поставляется с fetch, и есть другие сильные привязки .Библиотека также вызовет проблемы с зависимостью при обновлении. Она по-прежнему является реактивным маршрутизатором. V4 поддерживает RN, но dva по-прежнему является V2. Нам нужно дождаться, пока dva обновит реактивный маршрутизатор, прежде чем его можно будет использовать. Если это плагин - в и апгрейдить самостоятельно, такой проблемы не будет.

Под словом dva-core я подразумеваю трактовку малого ядра как dva-core, использование маршрутизаторов и т.п., а затем разработку нескольких схем интеграции по умолчанию, таких как внутренняя унифицированная версия компании, для среднего и вспомогательного офиса. , а для H5 - для небольших программ, рендеринга на стороне сервера и т. д.

2:00:
1. В реальной разработке бизнес-логика реализована в модели, и файл слишком велик. Какая связь между другим и сервисом? Услуга или запрос могут быть встроенными
2. Измените response-router на собственный плагин системы или что-то еще, цель состоит в том, чтобы освободить зависимость

Когда начнется 2.0?

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

TypeScript и RN.Надеюсь получить лучшую поддержку

Подумайте о другом, укажите значение по умолчанию namespace

В процессе использования dva всегда будут случаи, когда reducer не требует префикса, а текущая реализация dva должна предоставлять namespace , поэтому у меня есть предложение, если namespace - это default (или global , * ), мы думаем, что model ниже reducers - Без префикса

Лично подумайте о нескольких моментах:

• Не зависит от redux-saga , поэтому вы можете легко добавить некоторые функции (например, поддержку async / await)
• Разделить на несколько небольших модулей (например, один магазин, один маршрутизатор)
• Поддержка вложенной модели

Недавно мы смоделировали vuex на основе redux написали контрольную точку: https://github.com/d-band/yax

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

Могу ли я установить имя каталога маршрутов? Например, используйте контейнер
Фактически, я хочу разделить каталог по функциям, объединяя модель, сервис и контейнер, иначе переход к нескольким каталогам разрушит поток сердца. Чтобы узнать, что такое user.js, открытый на вкладке над возвышенным, я уже назвал его так: user.jsx, user.model.js, user.service.js. Соберите вместе user / model.js, service.js, container.js

Теперь поддерживаются организации каталогов, такие как

@xufei
@sorrycc

Рассматриваете ли вы при немоделировании поддержку передачи редуктора для уничтожения неиспользуемых данных состояния?

Ручное управление слишком хлопотно, рекомендуется напрямую реализовать набор GC.

Обновите pathToRegexp, его методы синтаксического анализа и компиляции нельзя использовать напрямую

Согласование лучше, чем конфигурация, поскольку оно снижает взаимосвязь с другими проектами или технологическими стеками.

Бизнес с эффектами слишком тяжел, и идея расширения модели неплоха.

@nihgwu лично согласен с тем, что «ядро

@sorrycc Есть ли у

Я очень надеюсь, что dva-cli сможет создать шаблон TypeScript.

dva-core уже можно использовать в апплетах WeChat

@yautah пробовали? Вы можете поделиться планом после того, как попробуете его.

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

Надеюсь на поддержку dva-cli для поддержки стилуса

Поддержки ssr нет.

Как настроить HRM, API написания сравнительно мало