Сейчас я работаю над проектом под названием 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 }
Есть множество преимуществ сообщений как функций
- Тип сообщений НЕ String. Вы никогда не ошибетесь в написании типа сообщения. Даже если вы это сделали, браузеры немедленно выдадут вам ошибку. Попрощайтесь с огромным списком констант типа действия.
- Не нужно писать авторам сообщений. Хотите написать сообщение? просто позвоните
new Increment()
и получите его. В Redux вы должны писать создателей действий каждый раз, поэтому вы получаете'INCREMENT'
как тип действия иfunction Increment()
как его создатель, двойной код для написания. - Сообщения создаются автоматически. В большинстве случаев The Elm Architecture создает сообщения автоматически, вам не нужно писать
new Increment()
самому себе, просто передайтеIncrement
обработчикам, пусть они будут генерировать сообщения для вас. - Поддержка печатного языка. Поскольку сообщения являются экземплярами, при использовании такого языка, как 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 здесь, любой вклад или отзыв приветствуются.