Dva: [Обсуждение] -Заявление о зависимости исходных данных страницы

Созданный на 17 дек. 2017  ·  3Комментарии  ·  Источник: dvajs/dva

В официальном документе и примере hackernews метод прослушивания совпадающего URL-адреса истории в подписке модели используется для загрузки исходных данных для страницы следующим образом.

//摘自api文档
app.model({
  namespace: 'todo',
  // ... 
  subscriptions: {
    setup({ history, dispatch }) {
      // Subscribe history(url) change, trigger `load` action if pathname is `/`
      return history.listen(({ pathname }) => {
        if (pathname === '/') {
          dispatch({ type: 'load' });
        }
      });
    },
  },
});

Портал: аналогично написанная модель предметов от dva-hackernews

Это отличается от загрузки данных в течение жизненного цикла компонентов страницы. Например, в том же примере с hackernews мы можем выбрать отправку соответствующего действия эффектов в componentWillMount или componentDidMount ListPage, чтобы сделать запрос, и даже думать из с точки зрения серверного рендеринга. Вы можете добавить дополнительный жизненный цикл (например, getInitProps из next.js), который будет отвечать за объявление зависимости от начальных данных для этого типа страницы.

При нынешнем способе помещения зависимости исходных данных страницы в подписку модели у меня есть следующие вопросы:

  1. Повторение логики сопоставления URL-адресов. Маршрутизатор обязан проанализировать параметры URL-адреса и передать их в бизнес-логику. На примере hackernews мы видим, что некоторые из них были повторены, и даже относительно "низкоуровневые" библиотека, такая как pathToRegex (за response-router / express), она также используется для сопоставления URL-адресов и синтаксического анализа)
  2. Разделение обязанностей: разные практики соответствуют разной семантике. Объявляет ли страница, от каких данных она зависит, или модель объявляет, по какому URL-адресу выполнять загрузку данных?
  3. Страница теряет контроль над запросом. Если страница хочет выполнить определенную логику после успешного или неудачного запроса, это будет сложнее реализовать, потому что сама страница не знает о действии загрузки данных.
  4. Как работать со сценариями рендеринга / изоморфизма сервера, на самом деле является продолжением 3. При рендеринге сервера вам нужно «сначала загрузить данные, от которых зависит страница, а затем выполнить рендеринг страницы», и если утверждение запроса не на уровне страницы это должно быть сделано. Это более хлопотно
  5. Кажется, что на дизайн подписки влияет вяз, но подписка на вяз на самом деле мало используется. Она используется только для работы со сценариями, такими как веб-сокет. Первоначальный запрос по-прежнему выполняется через оператор страницы init.

Конечно, dva не ограничивает, какой метод используется. Вполне возможно использовать жизненный цикл компонентов страницы в dva, но я думаю, что официальные документы и примеры, которые имеют наглядный эффект, используют другой метод. Очень вероятно, что Я не знаю, что нужно учитывать, я раньше добавил групповой вопрос WeChat, но не смог получить ответа (друг сказал, что это потому, что dva надеется, что компоненты страницы также являются функциональными компонентами, что действительно важно, но не кажется таким убедительным), поэтому я открыл вопрос. Простите, что беспокою.
@sorrycc

discussion wontfix

Все 3 Комментарий

крючок модели

              邮箱:[email protected]

Подпись была настроена NetEase Mail Master. В 16:30 17 декабря 2017 года Цинь Цзюньвэнь написал: В официальном документе и примере hackernews метод прослушивания совпадающего URL-адреса истории в подписке модели используется для загрузки исходных данных. для страницы следующим образом.
// Из документации api
app.model ({
пространство имен: 'todo',
// ...
Подписки: {
setup ({history, dispatch}) {
// Изменение истории подписки (URL), запуск действия load если путь равен /
вернуть history.listen (({pathname}) => {
if (путь === '/') {
отправка ({type: 'load'});
}
});
},
},
});
Портал: аналогично написанная модель предметов от dva-hackernews
Это отличается от того, что мы обычно видим при загрузке данных в жизненном цикле компонентов страницы. Например, в том же примере с hackernews мы можем выбрать отправку соответствующего действия эффектов в componentWillMount или componentDidMount ListPage, чтобы сделать запрос , и даже подумайте с точки зрения серверного рендеринга. Вы можете добавить дополнительный жизненный цикл (например, getInitProps из next.js), который будет отвечать за объявление зависимости исходных данных этой страницы.
При нынешнем способе помещения зависимости исходных данных страницы в подписку модели у меня есть следующие вопросы:

Повторение логики сопоставления URL-адресов. Маршрутизатор обязан проанализировать параметры URL-адреса и передать их в бизнес-логику. На примере hackernews мы видим, что некоторые из них были повторены, и даже относительно "низкоуровневые" библиотека, такая как pathToRegex (за response-router / express), она также используется для сопоставления URL-адресов и синтаксического анализа)
Разделение обязанностей: разные практики соответствуют разной семантике. Объявляет ли страница, от каких данных она зависит, или модель объявляет, по какому URL-адресу выполнять загрузку данных?
Страница теряет контроль над запросом. Если страница хочет выполнить определенную логику после успешного или неудачного запроса, это будет сложнее реализовать, потому что сама страница не воспринимает действие загрузки данных, как поступать с серверным рендерингом. / изоморфные сценарии. Фактически, это продолжение 3. При серверном рендеринге вам нужно «сначала загрузить данные, от которых зависит страница, а затем выполнить рендеринг страницы», и если выражение запроса не находится в уровень страницы вообще, сделать это будет хлопотнее.
Кажется, что на дизайн подписки влияет вяз, но подписка на вяз на самом деле мало используется. Она используется только для работы со сценариями, такими как веб-сокет. Первоначальный запрос по-прежнему выполняется через оператор страницы init.

Конечно, dva не ограничивает, какой метод используется. Вполне возможно использовать жизненный цикл компонентов страницы в dva, но я думаю, что официальные документы и примеры, которые имеют наглядный эффект, используют другой метод. Очень вероятно, что Я не знаю, что нужно учитывать, я уже добавил групповой вопрос WeChat раньше, но не смог получить ответа (друг сказал, что это потому, что dva надеется, что компоненты страницы также являются функциональными компонентами, что действительно важно, но не кажется таким убедительным), поэтому я открыл вопрос. Простите, что беспокою.
@sorrycc

- Вы получили это, потому что подписаны на эту цепочку. Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите чат.

{"api_version": "1.0", "publisher": {"api_key": "05dde50f1d1a384dd78767c55493e4bb", "name": "GitHub"}, "entity": {"external_key": "github / dvajs / dva", "title ":" dvajs / dva "," subtitle ":" Репозиторий GitHub "," main_image_url ":" https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png " , "avatar_image_url": " https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png ", "action": {"name": "Открыть в GitHub", "url": " https://github.com/dvajs/dva "}}, "updates": {"snippets": [{"icon": "DESCRIPTION", "message": "[Обсуждение] -О странице Проблемы зависимости данных (# 1402) "}]," действие ": {" name ":" Просмотреть проблему "," url ":" https://github.com/dvajs/dva/issues/1402 "}}}

@ yangbin1994

Что такое крючок у модели?
Я не видел этого в модельном документе .

Если предположить, что этот крючок есть, он не будет существенно отличаться от его выполнения в подписке. Приведенные выше 1–4 вопросы все еще существуют.

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время не было активности. Он будет закрыт, если больше не будет активности. Спасибо за ваш вклад.

Была ли эта страница полезной?
0 / 5 - 0 рейтинги