Сейчас я работаю над проектом под названием elm-architecture, который представляет собой Elm Architecture, реализованный на JavaScript.

Фон

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

Реализуйте это правильно

The Elm Architecture - это архитектура для языка Elm. Он во многом зависит от языковых функций, что делает код очень чистым.

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

Сравните архитектуру Elm с Redux

Что-то случилось: сообщения против действий

Вот как The Elm Architecture и Redux описывают «что-то произошло», например, события, вы обрабатываете их в зависимости от их типа.

В Redux действие - это простой объект, его тип - свойство.

{ type: ‘INCREMENT’ }
{ type: ‘DECREMENT’ }

И вот как вы с ними справляетесь

switch (action.type) {
  case 'INCREMENT':
    return state + 1
  case 'DECREMENT':
    return state - 1
}

Однако сообщения в The Elm Architecture - это функция.

function Increment() {}
function Decrement() {}

И вот как вы с ними справляетесь

switch (msg.constructor) {
  case Increment:
    return model + 1
  case Decrement:
    return model - 1
}

Есть множество преимуществ сообщений как функций

  1. Тип сообщений НЕ String. Вы никогда не ошибетесь в написании типа сообщения. Даже если вы это сделали, браузеры немедленно выдадут вам ошибку. Попрощайтесь с огромным списком констант типа действия.
  2. Не нужно писать авторам сообщений. Хотите написать сообщение? просто позвоните new Increment() и получите его. В Redux вы должны писать создателей действий каждый раз, поэтому вы получаете 'INCREMENT' как тип действия и function Increment() как его создатель, двойной код для написания.
  3. Сообщения создаются автоматически. В большинстве случаев The Elm Architecture создает сообщения автоматически, вам не нужно писать new Increment() самому себе, просто передайте Increment обработчикам, пусть они будут генерировать сообщения для вас.
  4. Поддержка печатного языка. Поскольку сообщения являются экземплярами, при использовании такого языка, как TypeScript, он даст вам отличные подсказки и помощь по коду.

Побочные эффекты: Cmd / Sub против промежуточного программного обеспечения

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

Архитектура Elm предоставляет простой способ устранения побочных эффектов - cmd / sub. В отличие от промежуточного программного обеспечения Redux, его нельзя объединять в цепочку, каждый менеджер побочных эффектов выполняет только свою работу.

Управление состоянием: модель / обновление против редукторов

И Redux, и Elm Architecture используют подход единого централизованного состояния. Разница в том, что Redux разделяет состояние на несколько редукторов, а в архитектуре Elm есть только одна модель с функцией обновления (вы можете рассматривать ее как один редуктор).

Преимущество редукторов в том, что их область действия невелика, вы можете обрабатывать их по частям, а в идеале вы даже можете повторно использовать их в своих приложениях. Плохо то, что вам нужно потратить время, чтобы решить, как разделить ваше состояние, если вы сделаете это неправильно, вы можете столкнуться с проблемами масштабирования. Также вы столкнетесь с вопросами вроде Как разделить состояние между двумя редукторами?

Архитектура Elm просто проста, только одна модель, никаких сомнений.

Подключение для просмотра: функция просмотра вызовов и поставщик / подключение

Redux рекомендует пользователям оборачивать компоненты компонентом Connect, когда это необходимо. Основная концепция - разделить представление и состояние, эта цель звучит великолепно, но цена также очень высока, вы пишете все больше и больше кода, такого как mapStateToProps, mapDispatchToProps, Provider и Подключиться для этого, действительно ли оно того стоит?

В The Elm Architecture вы передаете модель в функцию просмотра для визуализации вашего вида. В результате вид связан с моделью. Звучит плохо. Но это идея The Elm Architecture - никаких компонентов, только визуальные элементы.

Мы не думаем о компонентах многократного использования. Вместо этого мы сосредотачиваемся на функциях многократного использования… мы создаем многоразовые представления, разбивая вспомогательные функции для отображения наши данные.
- Scaling The Elm Architecture

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

Резюме

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

Если вы заинтересованы в использовании The Elm Architecture в JavaScript или у вас было достаточно написания шаблона в Redux, elm-architecture здесь, любой вклад или отзыв приветствуются.