Хуан Цзыи, в настоящее время работающий в отделе обработки данных Alibaba Data Center, отвечает за бизнес, связанный с продуктами данных. Основатель интерфейса интенсивного чтения, автор Dob фреймворка потока данных, автор визуального редактора gaea-editor, автор средства просмотра реагирующих изображений, поддерживает несколько библиотек компонентов интерфейса.
Эта статья написана Хуан Цзыи в"Салон технологий Ctrip - Практика передовых технологий нового поколения"делиться на .
Эта статья поможет вам понять, что такое mvvm, принцип mvvm и какая эволюция произошла за последние годы. В то же время тема mvvm используется для расширения до размышлений о различных интерфейсных решениях для потоков данных, формирования общего понимания интерфейсных потоков данных и помощи всем в выборе технологий в команде.
1. Концепция и разработка Mvvm
1. Mvvm и однонаправленный поток данных
Mvvm относится к двустороннему потоку данных, то есть к двусторонней связи между View-Model, которая соединена ViewModel. Как показано ниже:
Односторонний поток данных удаляет шаг Представление -> Модель, который должен быть привязан пользователем вручную.
2. Экология — встроенная и несвязанная
Многие интерфейсные фреймворки имеют встроенную функциональность Mvvm, например Knockout, Angular, Ember, Avalon, Vue, San и другие.
Так же, как и Redux, в фреймворке Mvvm также есть много библиотек, отделенных от фреймворка, таких как Mobx, Immer, Dob и т. д. Этим библиотекам нужен промежуточный уровень для соединения с фреймворком, такой как mobx-react, redux-box, доб-реагировать . Разделение позволяет фреймворку больше сосредоточиться на уровне представления, обеспечивая гибкое совместное размещение библиотек и фреймворков.
Фреймворк разделенного потока данных также интерпретирует архитектуру Mvvm на более высоком уровне абстракции, а именно: View — интерфейсный фреймворк, Model — (mobx, dob), ViewModel — (mobx-react, dob-react).
В то же время он также реализует разделение данных и инфраструктуры, что удобно для тестирования и обслуживания. Например, в следующем примере левая сторона — это независимое от платформы определение чистых данных/операций с данными, а правая сторона — это View + ViewModel:
3. Оперативная эффективность — обнаружение грязных данных и перехват геттеров/сеттеров
Хотя ранний механизм грязной проверки Angular был пионером mvvm, его эффективность мониторинга относительно низка, требуется N + 1 раз, чтобы подтвердить, есть ли изменение связи в данных, как показано на следующем рисунке:
Сейчас почти все фреймворки перешли на перехват геттеров/сеттеров для реализации мониторинга, и любые изменения данных могут быть завершены за один цикл обработки событий:
4. Грамматика — специальная грамматика и родная грамматика
Некоторым ранним платформам Mvvm требовалось вручную запускать обновления представления, и теперь этот подход почти заменен собственными операторами присваивания.
5. Метод изменения данных — Mutable и Immutable
Хотя синтаксис кода на следующем рисунке является изменяемым, результат может быть изменяемым или неизменным, в зависимости от встроенного механизма реализации платформы mvvm:
6. Два способа написания Connect
Так как mvvm поддерживает mutable и immutable, для нижнего слоя mutable мы используем синтаксис подключения левого изображения, а для нижнего слоя immutable нам нужно использовать синтаксис conenct правого изображения:
Для левого изображения, из-за изменяемого драйвера, все изменения данных будут автоматически вызывать обновление представления, поэтому не только обновление может быть выполнено за один шаг, но также может быть введен полный объем данных, поскольку неиспользуемые переменные не вызовут дополнительный рендеринг.
Для картинки справа из-за неизменяемого драйвера она не имеет возможности активно управлять обновлением вида, поэтому при изменении узла в правом нижнем углу во всей ссылке будет сгенерирован новый объект, который будут передаваться в представление для обновления слой за слоем через механизм обновления представления.
2. С TFRP на mvvm
Когда дело доходит до принципа mvvm, давайте начнем с TFRP.Подробности см. в разделе "реализация dob-framework". В этой статье в качестве примера используется dob framework, чтобы шаг за шагом представить, как реализовать mvvm. Эта статья представляет собой краткое введение.
1. Автозапуск и реакция
Автозапуск — это функциональный эффект TFRP, то есть он объединяет сбор и мониторинг зависимостей, а автозапуск реализуется реакцией, стоящей за ним.
2. React реализует автозапуск
Как показано на рисунке ниже, автозапуск является реакцией подписки на отслеживание и активно отправляет во время инициализации, активирует цикл из записи (подписки) и завершает подписку -> отслеживание -> модификация мониторинга -> подписка для завершения замкнутого цикла. .
3. Реализация трека
Каждая дорожка будет прослушивать событие геттера обратного вызова во время его выполнения и сохранять цель и свойствоKey в двумерной карте.При срабатывании любого геттера запросите зависимость из этой двумерной таблицы, а затем найдите соответствующий обратный вызов. и выполнить его.
4. Реализация View-Model
Поскольку автозапуск очень похож на функцию рендеринга представления, мы оборачиваем его в среду автозапуска, когда функция рендеринга инициализируется и выполняется, а второй рендер начинает обдирать внешний автозапуск, чтобы обеспечить привязку данных только один раз.
Таким образом, на основе оригинального механизма обновления реквизита слой представления добавляет функцию автозапуска для реализации эффекта автоматического обновления соответствующего представления путем модификации каких-либо данных.
3. Недостатки и решения Mvvm?
Почти все известные недостатки Mvvm имеют решения.
1. Невозможно отслеживать новые свойства
Студенты, которые использовали Mobx, знают, что для добавления несуществующего свойства в хранилище необходимо использовать метод extendObservable. Эта проблема решена и в Dob, и в Mobx4.0.Решение заключается в использовании прокси вместо Object.defineProperty:
2. Асинхронная проблема
Поскольку геттер/сеттер не может получить текущую функцию выполнения, ее можно решить только с помощью глобальных переменных, поэтому функция обратного вызова автозапуска не поддерживает асинхронность:
3. Проблема вложения
Из-за функции реакции поддерживаются только синхронные функции обратного вызова, поэтому при вложенности автозапусков порядок связывания зависимостей, скорее всего, будет нарушен. Решение состоит в том, чтобы поместить вложенный автозапуск в конец очереди выполнения, как показано на следующем рисунке:
4. Нет снимка данных
Наиболее критичным моментом mutable является то, что он не может делать моментальные снимки данных и не может выполнять обратный отсчет времени, как избыточность. Если есть проблема, кто-то ее решит, и библиотека Immer от автора Mobx отлично решает проблему.
Принцип заключается в том, чтобы вернуть прокси-объект через прокси и внутренне заменить изменяемые изменения объекта с помощью неглубокой копии. Конкретный принцип описан в моей предыдущей статье «Интенсивное чтение исходного кода Immer.js».
5. Изоляция без побочных эффектов
Поскольку действие функции mvvm поддерживает асинхронность, многие люди будут одновременно отправлять запросы в действие и изменять хранилище, чтобы побочные эффекты запроса нельзя было изолировать от хранилища. При этом изменяемая модификация хранилища сама по себе является побочным эффектом.
Хотя можно разделить функцию запроса на другое действие, полностью избежать человеческого фактора невозможно.
Так как Immer.js, по крайней мере, с точки зрения поддержки метапрограммирования, mutable не обязательно имеет побочные эффекты, это может быть нулевыми побочными эффектами:
typescript function inc(obj) { return produce(obj => obj.count++) }
Кажущаяся изменяемой запись выше на самом деле является чистой функцией с нулевыми побочными эффектами, что эквивалентно следующей записи:
typescript function inc(obj) { return { count: obj.count + 1, ...obj } }
Для изоляции побочных эффектов также можно сделать двойную инкапсуляцию:
4. Организационная форма магазина МВВМ
Mvvm хранит структуру кода в проекте, тоже постоянно меняется, вот 4 распространенные формы.
1. Форма объекта, представляющая фрейм – mobx
mobx создал самую простую форму организации магазина mvvm, которая в основном является формой организации магазина каждого встроенного фреймворка mvvm.
2. Класс+инъекция, представляющая фреймворк — доб
Доб приложил много усилий в форме организации магазина, улучшив связь между магазинами посредством внедрения зависимостей и реализовав сетевую структуру «многие к одному» магазины -> действие.
3. Структура данных, представляющая фреймворк – mobx-state-tree
mobx-state-tree представляет собой типичную структурированную организацию магазина, которая подходит для интегрированной разработки приложений, например, необходимо связать детализированные данные между многими страницами.
4. Конвенция и интеграция, представляющие рамки - два класса
Класс dva - это режим интеграции. Это упрощенное решение для сложного шаблонного кода редукции. Естественная интеграция и условность - это направление упрощения.
Кроме того, эта схема больше похожа на слой данных dsl, благодаря чему один и тот же набор кода может иметь разные базовые реализации.
5. Mvvm против реактивного программирования
И Mvvm, и реактивное программирование имеют наблюдаемые характеристики, которые легко различить по следующим двум диаграммам:
Красная линия выше — это наблюдаемая часть mvvm, которая относится к действию автозапуска при изменении данных.
Красная линия выше — это наблюдаемая часть реактивного программирования, которая относится к процессу отправки потока источником данных.
Сочетание Mvvm и реактивного программирования
Поскольку redux можно комбинировать с rxjs (редуктивно-наблюдаемый), то и mvvm.
Вот идея для этого сценария:
rxjs используется только для изоляции побочных эффектов и обработки данных, mvvm имеет возможность изменять хранилище и точно обновлять используемое представление.
6. Резюме
Укажите схему потока данных в соответствии с бизнес-сценарием. Для схемы потока данных нет серебряной пули. Только придерживаясь сцены, вы можете найти наиболее подходящую схему.
Узнав о разработке и эволюции mvvm и комбинировании различных схем потоков данных, вы обнаружите, что существует гораздо больше схем потоков данных.
Нажмите «Прочитать исходный текст» в конце статьи, чтобы на месте посмотреть видео, которым поделился лектор.
【Рекомендуется к прочтению】