1. Вход игроков
Когда дело доходит до управления состоянием React, многие люди даже не хотят упоминать об этом.
Redux: Игрок №1, самый популярный, выигралreact-redux
использоваться вместе. Меня не волнует асинхронность, так что я часто слышу?redux-thunk
,redux-saga
Это его подчиненный, который специализируется на подтирании задницы. Особенность в том, что его сложно использовать, если вы используете его в соответствии с официальной документацией, вы в основном захотите умереть. Рекомендуемое чтение:Ууху. Call.com/question/33…
Mobx: Конкурсант №2, использование метода мониторинга противоречит мышлению React, есть проблема с мышлением, мошенник!
dva: Обертка Redux, использующаяredux-saga
, формулировка генератора, хочу умереть.
Rematch: пакет Redux, аналогичный dva,model
разделен наreducers
а такжеeffects
, недостаточно лаконична.
Реклама: Итак 🐤 Retalk — самый простой, самый простой пакет Redux в истории, не пропустите его, когда будете проходить мимо:GitHub.com/школьные школы/…
2. А вот и React Hooks
В любом случае, хуки здесь. Предыдущее управление состоянием использовалось для предыдущих методов разработки. Чтобы немного выразить хуки, мы добавим еще несколько.useBlabla()
Сделанный.
По сравнению с легкостью Крюков все они кажутся неуклюжими, старомодными и небрежными.
Существует ли какое-либо управление состоянием, посвященное хукам? В настоящее время нет никого, на что все рассчитывают, в основном старые игроки заняты на подработках, что немного невзрачно.
Недостаточно революционно.
3. Зачем нужно государственное управление?
Один из них заключается в решении проблемы связи смежных компонентов.
Хотя ее можно решить путем «продвижения государства», есть две проблемы:
-
Каждый раз, когда дочерний компонент обновляется, он запускает общее обновление родительского компонента, ответственного за выдачу состояния (использование Context также имеет эту проблему), а затем пишет много
PureComponent
,shouldComponentUpdate
, вы все еще можете увидеть код? Мусор в дизайне React написан достаточно, очень плохо. -
Если логики много, то она вся прописана в родительском компоненте, код можно еще посмотреть? Он вообще не принимает во внимание чувства родительского компонента.
Поэтому «улучшение состояния» — не лучшая идея, и управление состоянием по-прежнему требуется.
Кроме того, одним из важнейших преимуществ государственного управления является:
Он может извлекать из компонента логику «взаимодействия с сервером» и «манипулирования данными», а компоненту нужно только получать обработанные данные. Это эквивалентно отделению сервисного уровня, что является хорошим способом разработки.
Код логически разделен, каждый выполняет свои обязанности, а компонент делает то, что должен делать компонент — это самое большое преимущество.
Поэтому нам нужно государственное управление.
4. Какое государственное управление нам нужно?
Если вы начнете с Redux, вы обнаружите, что он предоставляет глобальное хранилище. а потом? Тогда он ничего не сказал. Если есть какие-то проблемы, просто решите их сами. Я пошел спать первым.
При реальном развитии бизнеса наиболее распространенным сценарием является необходимость различать разные «модули», что является основным требованием.
Vuex более прагматичен и предоставляетmodules
Концепция чего-либо.
А Редукс? Конечно, рассчитывать нужно на себя, нам нужно лишь подать идею, ведь такую простую вещь вы можете сделать сами.
Без спецификации дизайна API это неизбежно приведет к бесчисленному количеству различных реализаций. (Одинарная ставка x 2)
CHAOS.
Какое государственное управление нам нужно?
Нам нужно государственное управление, соответствующее национальным условиям начального этапа социализма с китайской спецификой.
Нам нужно иметь возможность разделить разные модули, модули независимы, и в то же время модули могут свободно взаимодействовать.
Многие библиотеки управления состоянием учитывают только «независимость» модулей, но умалчивают о «коммуникациях», что не является дружественным.
Независимые и подключенные — вот что такое модули.
5. Как делятся модули?
Вообще говоря, рекомендуется разделить различные модули в соответствии с основной записью маршрутизации, что также является идеей в dva (ее папка называется простоroutes
).
Это также соответствует естественному образу мышления, разделяющему маршруты, то есть естественному мышлению о том, что они принадлежат разным модулям.
И каждый модуль управления состоянием, который мы называем «моделью», рекомендуется привязывать к входному компоненту маршрутизации, каждый входной компонент и его подкомпоненты соответствуют модели в целом.
---A
index.jsx
model.js
---B
index.jsx
model.js
---C
index.jsx
model.js
6. Как взаимодействуют модули?
Модули независимы, нет сомнения, что модули, модули, не являются независимыми, также называются модулями?
Как модуль общается?
В компоненте можно получить свою модель и другие модели, что несложно.
В основном, внутри модели каждый из своих методов должен вызывать друг друга, и в то же время он должен получать данные и методы других моделей, в этом смысл коммуникации.
Это должно быть достаточно просто.
Это хороший и продуманный дизайн.
7. Как получить модель в компоненте Hooks?
Напрямую, мы хотим получить доступ к модели через хуки в компоненте.
const { someStateInA, someActionInA } = useModel(a);
// or
const { someStateInA, someActionInA, someStateInB, someActionInB } = useModels(a, b);
useModel()
Таким образом, если вы хотите спроектировать модель, вам нужно ввести файл модели в компонент, который недостаточно свободен, чтобы зависеть от необходимости импортировать файл.
Пока операция хлопотная и кода написано больше, это не очень хороший дизайн.
Кроме того, крючки должны сделать код более четко, и мы не можем нарушить дизайн философии общей системы, такой как MOBX.
Поэтому модель получает лучшее для отделения,useModels(a, b)
Способ введения нескольких моделей одновременно недостаточно ясен.
Не могу полагаться на файл, введение понятно, поэтому:
const { someStateInA, someActionInA } = useModel('a');
const { someStateInB, someActionInB } = useModel('b');
Зависит от строки, поэтому вам не нужно импортировать файлы в каждый компонент.useModel()
Доступна только одна модель, и код достаточно ясен.
Вот такой дизайн нам нужен.
8. Как спроектировать структуру модели?
Вообще говоря, модель можно разделить на две части: данные (state
) и методы манипулирования данными (reducers
,effects
).
reducers
а такжеeffects
или в Vuexmutations
а такжеactions
, состоит в том, чтобы различать прямые изменения и асинхронные операции, синхронные функции и асинхронные функции. Недостаточно лаконично, можно ли это объединить в одно?
Ответ да, мы называем этоactions
.
Метод обновления состояния напрямую внедряется в модель, поэтому действие может быть синхронным или асинхронным, оно просто вызывается как функция.
Поэтому модель разделена на две части:
exports default {
state: {},
actions: {},
}
9. Как устроена модельная коммуникация?
Моделируйте общение, в основном для достижения доступа к другим вещам в действии.
Свободное и неограниченное общение.
Действие должно иметь доступ к следующему: 1. своему собственному состоянию, 2. своему собственному действию, 3. состоянию других модулей, 4. действиям других модулей и 5. своему собственному средству обновления состояния.
Для упрощения вам необходимо получить доступ: 1. к собственной модели, 2. к другим моделям, 3. к собственному средству обновления состояния.
Еще раз упростим: 1. модель, 2. свой апдейтер состояния.
Так что на самом деле нужны только два метода:getModel()
а такжеsetState()
.
getModel()
получить себе,getModel('other')
Получите другие.
Как получить эти два метода?
-
пройти через
this
доступ. Но мы разрабатываем управление состоянием для хуков, а хуки предназначены для отказа отthis
,Опять таки --Не может нарушать философию дизайна системы. -
В Vuex контекст вводится в первый параметр функции при вызове функции.довольно нелогично, отказаться от этого пути.
-
Приходит метод импорта в файл модели, что слишком хлопотно.Пока операция хлопотная и кода написано больше, это не очень хороший дизайн..
Таким образом, единственный способ (который также можно увидеть в дизайне Rematch) — это внедрить методы в параметры.
то есть положитьactions
в функцию:
exports default {
state: {},
actions: ({ getModel, setState }) => ({
someAction() {
const { someState, someOtherAction } = getModel();
}
}),
}
Учитывая здесь эстетическую проблему,getModel()
Потому что будет использовано много действий, и когда они на самом деле написаны, потому чтоl
Проблема высоты безобразна, поэтому API упрощается доmodel()
.
model()
получить себе,model('other')
Получите другие.
10. Что такое флуки?
Так родились флуки, Flukes:
🍸 выглядит→GitHub.com/школьные школы/…
import { setModel, useModel } from 'flooks';
const a = {
state: {},
actions: ({ model, setState }) => ({
someAction() {
const { someState, someOtherAction } = model();
...
setState(payload);
}
}),
}
setModel('a', a);
function A() {
cosnt { someState, someAction } = useModel('a');
return (
...
)
}
Естественная модульная поддержка.
Есть только два API,setModel()
а такжеuseModel()
.
плюсactions
Два параметра ,model()
а такжеsetState()
,это все.
Достаточно просто сделать все.
И еще кое-что: философия дизайна.
Децентрализовать, децентрализовать, децентрализовать.
Все для облегчения развития.
Больше нет магазина дистрибутива верхнего уровня, папки магазина или файла store.js.
Не требуется верхний слойcreateStore()
, верхний слой не нуженProvider
.
При регистрации модели нет необходимости сначала вносить модель в централизованный файл, все можно сделать в своей папке.
использовать напрямуюsetModel()
Подключите компонент к модели, это так просто.
Модульность, модульность, простота и гибкость — вот наша философия.
Каждый компонент и модель представляет собой самоорганизацию, и в то же время к ним можно получить доступ в любой точке мира. Они могут встречаться в любом уголке мира, не отчитываясь перед соответствующими отделами.
Это наша философия: независимость, свобода, личность, мир.