Redux вообще не должен ничего «знать, чтобы диспетчеризовать». Его задача — только хранить состояние. У вас должен быть отдельный кусок программы, ответственный за перехват тех или иных action'ов и за то, чтобы на это как-то отреагировать (в том числе взять текущий стейт, проанализировать его и, вероятно, запустить какие то экшены).
Ну нужно пытаться вешать на Redux то, что выходит за рамки его ответственности.
Страница может быть какая угодно. Вопрос в том, какая именно, и какой уровень отзывчивости и интерактивности ваши пользователи ожидают. Оба подхода имеют право на жизнь, очень зависит от конкретного сайта/приложения и того, какие действия с его помощью производят ваши пользователи. Просто не надо все под одну гребенку и говорить, что перезагрузка страницы — единственный тру-способ работы с веб-приложениями.
Ну, я именно это имел в виду под «хранением и управлением состояния». Надо было добавить «и корректному отображению всего этого на UI». И тут становится понятно, что и virtual DOM не просто так придумали и всякие другие штуки для этого — чтобы была возможна концепция «UI — это функция от состояния». Но автор комментариев выше настаивает на том, что все это не нужно, и я, наравне со многими другими, с этим несогласен :)
Ну, вы как-то даже и не хотите видеть каких-то преимуществ SPA-приложений (а люди с вами зачем-то спорят). Если вам хватает ваших инструментов — у вас же их никто не отбирает. У всех задачи опять же разные. Всякие чисто «хайповые» штуки со временем уходят или находят свою нишу, а вот полезные паттерны — остаются. Неужели вы думаете, что все и каждый вокруг вас — хипстер, которому нравятся модные словечки и использует такой подход только из за своей хипстеровости (есть такое слово?) :)
Возьмем тот же Реакт и его серверный рендеринг — и вот вам вполне себе альтернативный вариант написать чисто серверный UI (можете даже не подрубать React на клиенте). Кому-то удобнее, кому-то нет, но это еще один полезный паттерн.
Ну очень уж притянутый за уши пример. Вывести какой-то текст во все элементы с таким-то классом — элементарно. Во фронтенде реально сложно — хранить и управлять состоянием. Рендерить — чем угодно и как угодно — просто.
Ну, этот паттерн, который называют то «saga», то «process manager» — как раз об этом. Он описывает чистую логику, результатом которой являются те или иные «action»-ы. Тем самым хранилище состояния (Redux) только тупо хранит состояния и меняет его с помощью редьюсеров, а сама логика обрабатывается специализированными функциями.
Тут не нужно придумывать отдельный паттерн для «бизнес-логики», чтобы как-то технически отделить ее от логики приложения. Просто не надо в кучу мешать (разные «саги», разные ключи в хранилище стейта, все такое).
А кто мешает применять DDD? Просто данные будут в сторе, а логика — отдельно — в функциях, сагах, и всяких таких штуках. Разделение ответственности же, до сих пор же идут споры о «правильном DDD» — никто не говорит, что для этого нужен один мутабельный объект модели для каждой сущности с методами поведения. Концептуально DDD никто не мешает использовать.
P.S. На практике немного сложнее, в сторе обычно находятся не только данные «domain model», а куча разного рода другого состояния приложения.
Ну она синхронизирует текущую позицию в store и обратно — полезно для Time Travel, доступа к данным метонахождения через Redux, что позволяет компоненту в ряде случаев не зависеть от роутера. Но это совершенно точно не «альтернатива» :)
Они работают с единичными значениями «over time» — то есть, с течением времени. Вот и асинхронность. Никто не мешает сделать поток из массива и разом пустить его через цепочку операторов стрима. Получится своего рода «асинхронный массив» (хотя и не совсем, но результат, как мне кажется, будет именно тот, что нужен).
Тут, собственно, весь вопрос сводится к тому, что именно вы хотите делать с массивами с практической точки зрения?
А какова должна быть практическая польза от этого дела. Еще не совсем понятно само определение «утечек», что это?
P.S. Что-то мне подсказывает, что на самом деле вам нужны Observables — действительно мощнецкий инструмент для борьбы с асинхронностью. Посмотрите в сторону RxJS/xstream/most.js. Или я что-то упустил? :)
Совершенно верно. Только для этого вовсе не обязательно представлять экшены именно в виде стрима — просто последовательность экшенов, неважно каким образом запущенных. Стрим удобен для контекста (если хотите реактивный стиль), редьюсеру ж по барабану, как он там вызывается.
Мутации — синхронные и чистые, редьюсеры, так сказать, или транзакции.
А что значит «чистые»? В примере в статье меняется переданный в качестве аргумента объект — или под чистотой вы не имеете в виду «pure function»?
И плюс, между мутациями и редьюсерами фундаментальная разница. Редьюсеры как раз-таки «pure», это чисто функции, они ничего не меняют, а возвращают новый стейт.
Есть альтернативное мнение, что модель должна быть исключительно тупой и в идеале вообще генериться автоматом на базе некого формального описания структуры данных.
Так это и будут голые данные, зачем тут еще что-то «генерить»? (кроме как чисто какие-либо объекты ORM или вроде того — но это уже детали реализации).
Придерживаюсь точки зрения, что модель — это данные плюс поведение (бизнес-логика), а не только данные.
Rails вполне подходит для создания API, так что, пожалуй, и правда дело вкуса. В Штатах полно компаний и стартапов, которые сидят именно на Рельсовом стеке и вполне себе счастливы, даже несмотря на производительность Ruby (субъективное мнение — производительности бы Ruby, конечно, побольше, особенно учитывая, что здесь же под боком есть node.js, Golang, да и связка Elixir/Phoenix весьма активно набирает обороты). «Виной» тому как раз удобство и огромное количество наработок для всего и вся.
У статьи, конечно, несколько громкий заголовок — async/await — вовсе не шаг назад, особенно если программировать в императивном стиле (а он именно для этого и появился — не все пишут в функциональном и/или реактивном стиле). Аргумент автора лишь в том, что когда привыкаешь к функциональному подходу, он сам по себе уже кажется чище и элегантнее.
У меня async/await был самой ожидаемой фичей ES-Next, пока не пришлось столкнуться с Observables :) Теперь async/await, в общем-то, не у дел, но это и не значит, что он плох.
Ну и, к слову, несмотря на то, что код выглядит как синхронный, он именно что только «выглядит» так — асинхронность все равно надо держать в уме, и, поскольку await разворачивается в Promise, все равно нужно понимать, как именно он это делает.
А, в таком случае — вообще никаких нареканий, так можно и это, в общем-то, не bad practice. Тут скорее наоборот — иметь в props экшены с уже «прошитыми» props бывает просто удобно, чтобы каждый раз не прокидывать их внутри компонента. Я сам тоже предпочитаю эту логику убирать за его пределы, оставляя презентационному (presentational/dumb) компоненту минимум простора для принятия подобных решений.
Я думал, что речь о том, что стейт разбирается внутри, скажем, togglePlay(). Если myState — это уже нужный компоненту кусок стейта — это неплохо. Однако bad practice тут в том, что ваш компонент вообще знает, что что-то хранится в каком-то там стейте, вы его передаете туда-cюда. В этом плане еще лучше, если компонент вообще не будет знать, откуда берутся props (из стейта, переданы вручную, и так далее), это позволяет его легко переиспользовать. А ко всему прочему это проще тестировать.
Ну можно же передавать туда и просто свои props
Куда «туда»? :)
Кстати, как у вас в примере 'myState' оказывается аргументом обработчика onClick? Там же SyntheticEvent.
Bad practice, потому что тогда компонент должен знать о структуре стейта слишком много — больше, чем ему полагается для своей функциональности. То же касается и селекторов. В простых приложениях это может работать, но с ростом количества фич это становится все сложнее поддерживать (при изменении структуры state'а приходится вносить изменения в компоненты, селекторы и так далее).
Ну тут считайте, что формы просто используют Redux как хранилище состояния, вместо хранения его в компонентах. Там отдельный редьюсер, и эта часть state ничего не знает про остальные. С этой частью стейта обычно не работают напрямую (однако иногда это бывает удобно, например, вручную залить серверной валидации ошибки в стейт в обход того, что предлагает redux-form).
Ну нужно пытаться вешать на Redux то, что выходит за рамки его ответственности.
Возьмем тот же Реакт и его серверный рендеринг — и вот вам вполне себе альтернативный вариант написать чисто серверный UI (можете даже не подрубать React на клиенте). Кому-то удобнее, кому-то нет, но это еще один полезный паттерн.
Ну очень уж притянутый за уши пример. Вывести какой-то текст во все элементы с таким-то классом — элементарно. Во фронтенде реально сложно — хранить и управлять состоянием. Рендерить — чем угодно и как угодно — просто.
Тут не нужно придумывать отдельный паттерн для «бизнес-логики», чтобы как-то технически отделить ее от логики приложения. Просто не надо в кучу мешать (разные «саги», разные ключи в хранилище стейта, все такое).
P.S. На практике немного сложнее, в сторе обычно находятся не только данные «domain model», а куча разного рода другого состояния приложения.
(Более чем) реальная альтернатива react-router-у — junctions.js.
Тут, собственно, весь вопрос сводится к тому, что именно вы хотите делать с массивами с практической точки зрения?
P.S. Что-то мне подсказывает, что на самом деле вам нужны Observables — действительно мощнецкий инструмент для борьбы с асинхронностью. Посмотрите в сторону RxJS/xstream/most.js. Или я что-то упустил? :)
А что значит «чистые»? В примере в статье меняется переданный в качестве аргумента объект — или под чистотой вы не имеете в виду «pure function»?
И плюс, между мутациями и редьюсерами фундаментальная разница. Редьюсеры как раз-таки «pure», это чисто функции, они ничего не меняют, а возвращают новый стейт.
Так это и будут голые данные, зачем тут еще что-то «генерить»? (кроме как чисто какие-либо объекты ORM или вроде того — но это уже детали реализации).
Придерживаюсь точки зрения, что модель — это данные плюс поведение (бизнес-логика), а не только данные.
У меня async/await был самой ожидаемой фичей ES-Next, пока не пришлось столкнуться с Observables :) Теперь async/await, в общем-то, не у дел, но это и не значит, что он плох.
Ну и, к слову, несмотря на то, что код выглядит как синхронный, он именно что только «выглядит» так — асинхронность все равно надо держать в уме, и, поскольку await разворачивается в Promise, все равно нужно понимать, как именно он это делает.
Куда «туда»? :)
Кстати, как у вас в примере 'myState' оказывается аргументом обработчика onClick? Там же SyntheticEvent.
В оригинале — «You know a site has its shit together when…». Тут смысл прямо противоположный, особенно в контексте самой статьи :)