Тут вопрос терминологии. Я в этом контексте под «ресурсом» имел в виду «сущность», но, правда, не написал про отличие сущности от «фичи».
Можно сказать, что поиск — это ресурс со своей семантикой, и отличие тут как раз в том, что если какой-нибудь заказ (/orders/{order_id}) — это ресурс-сущность, поиск — это ресурс-фича, так что он всегда доступен.
Именно — если _ресурс_ не найден — то, как по мне, ничего плохого в 404 нет.
В примере автора же — поиск, который не какой-то конкретный ресурс, которого может не быть. Он есть всегда и всегда успешен, даже если ничего не найдено — «ресурсом» в контексте REST в данном случае будет «результат поиска» (а он может быть и пустым), а не его содержимое. Пользователь/клиент здесь не ошибся. А вот попытка загрузить данные с URI несуществующего ресурса — вполне ошибка, поэтому 404.
И не калорий конкретно — а именно от непревышения количества углеводов, иначе не работает. Про пищевые привычки — очень точно, причем прям надолго, нужно сменить образ питания (и это вовсе не значит жрать только творог 0,1% и яблоки круглыми сутками), временные «похудательные диеты» — совершенно бестолковая штука.
Поддерживаю полностью, первые два — приятный синтаксический сахар, а пайплайн — это прямо новая парадигма, по сути, API библиотек будут создаваться с учетом него, это круто.
Ну вы, по сути, на Redux и делаете фрактальный стейт (можно было об этом, собственно, явно в статье указать). Концептуально очень похоже на Fractal или cycle-onionify.
В отличие от Redux, MobX использует наблюдаемые объекты состояния, и API, основанное на принципах функционального реактивного программирования
Ага, особенно «функционального» — в то время как MobX до мозга костей ООП (очень уж полагается на `this`) и предполагает больше императивный стиль, нежели функциональный :)
Ну, MobX вообще не завязан на React технически — его можно хоть с Angular использовать или еще чем-нибудь. Если речь про официальный байндинг mobx-react — то он официально поддерживает React 16. Да ну и там нечему особо сломаться-то.
Нет, все правильно, Redux — синхронный. Но вот экшены могут как угодно запускаться — это уже просто за пределами ответственности Редакса.
Однако где-то это делать все же надо и тут — вариантов масса и тут VladVR неправ, что действие не может порождать действие — может (оба действия с соответствующим изменением стейта), вполне себе распространенный паттерн «process manager»/«saga», как раз для асинхронности. Везде есть свои нюансы, но совсем без асинхронщины/эффектов — никак в реальном приложении.
Да вообще как здрасьте. Как вывести космический корабль на орбиту? Да все банально при любом раскладе — определить траекторию, спроектировать корабль (незначительная мелочь), построить его, запустить двигатели и произвести взлет.
Конечно, Redux — не «rocket science», но за этим вот «выполнить экшены» — куча тех еще компромиссов и ухищрений.
DOM является функцией от `props` компонента — в ней может быть намешано все, что угодно, хотя обычно бОльшая часть — да, из глобального стора. Вы так говорите, будто это что-то плохое :)
P.S. Совершенно верно, редьюсеры можно использовать на любом уровне для любого стейта.
Ну, скажем так, его задача наметить паттерн для этого (dispatch, actions, middlewares, reducers), но не обязательно предлагать непосредственный механизм для этого (вместо него — предлагается подключать что-то свое как middleware).
UPDATE: Не то, чтобы это хорошо или плохо — с одной стороны, это дает больше гибкости, но с другой — все делают кто во что горазд :) Особенно когда сложность приложения выходит за пределы разумности применения простых вещей вроде redux-thunk (который, вроде как стартовая точка и он же — первый middleware, с которым все сталкиваются).
«Как минимум, MobX нормально оперирует привычными многим бэкендерам полноценными объектами, инкапсулирующими данные и поведение.»
А кто сказал, что всем нужно именно это? Это просто другой подход. Просто mobx как решение и хранит состояние, и имеет весь инструментарий для его управления. Плюс реактивность MobX, но это немного другая тема.
Redux же очень прост, но, по сути, действительно, умеет только хранить состояние, да и все. Ему нужно что-то, что будет поддерживать весь его (потенциально) навороченный стейт в порядке и согласованности. Причем, с ростом проекта, таких сценариев становится все больше, а они сами становятся все сложнее. Нужна асинхронность, опять же. Отсюда и появляются redux-saga, redux-observable (реактивные «саги»), сам я предпочитаю вообще Cycle.js использовать для подобного рода логики.
Так что, тут просто разница подходов и, по сути, дело вкуса. Но почему то мне кажется, что Redux придется по душе многим, или даже большинству, именно из за своей прямолинейности и простоты.
Можно сказать, что поиск — это ресурс со своей семантикой, и отличие тут как раз в том, что если какой-нибудь заказ (
/orders/{order_id}) — это ресурс-сущность, поиск — это ресурс-фича, так что он всегда доступен.В примере автора же — поиск, который не какой-то конкретный ресурс, которого может не быть. Он есть всегда и всегда успешен, даже если ничего не найдено — «ресурсом» в контексте REST в данном случае будет «результат поиска» (а он может быть и пустым), а не его содержимое. Пользователь/клиент здесь не ошибся. А вот попытка загрузить данные с URI несуществующего ресурса — вполне ошибка, поэтому 404.
Касаемо «серверлесса», кстати, всегда было непонятно, нахрена его так называют, когда там вполне себе сервер O_o
Есть варианты
Ага, особенно «функционального» — в то время как MobX до мозга костей ООП (очень уж полагается на `this`) и предполагает больше императивный стиль, нежели функциональный :)
Ну, MobX вообще не завязан на React технически — его можно хоть с Angular использовать или еще чем-нибудь. Если речь про официальный байндинг mobx-react — то он официально поддерживает React 16. Да ну и там нечему особо сломаться-то.
Однако где-то это делать все же надо и тут — вариантов масса и тут VladVR неправ, что действие не может порождать действие — может (оба действия с соответствующим изменением стейта), вполне себе распространенный паттерн «process manager»/«saga», как раз для асинхронности. Везде есть свои нюансы, но совсем без асинхронщины/эффектов — никак в реальном приложении.
Вообще, тренд к «фрактальному стейту» идет — Freactal, Mobx State-Tree, cycle-onionify, Elm Architecture.
Конечно, Redux — не «rocket science», но за этим вот «выполнить экшены» — куча тех еще компромиссов и ухищрений.
P.S. Совершенно верно, редьюсеры можно использовать на любом уровне для любого стейта.
UPDATE: Не то, чтобы это хорошо или плохо — с одной стороны, это дает больше гибкости, но с другой — все делают кто во что горазд :) Особенно когда сложность приложения выходит за пределы разумности применения простых вещей вроде redux-thunk (который, вроде как стартовая точка и он же — первый middleware, с которым все сталкиваются).
А кто сказал, что всем нужно именно это? Это просто другой подход. Просто mobx как решение и хранит состояние, и имеет весь инструментарий для его управления. Плюс реактивность MobX, но это немного другая тема.
Redux же очень прост, но, по сути, действительно, умеет только хранить состояние, да и все. Ему нужно что-то, что будет поддерживать весь его (потенциально) навороченный стейт в порядке и согласованности. Причем, с ростом проекта, таких сценариев становится все больше, а они сами становятся все сложнее. Нужна асинхронность, опять же. Отсюда и появляются redux-saga, redux-observable (реактивные «саги»), сам я предпочитаю вообще Cycle.js использовать для подобного рода логики.
Так что, тут просто разница подходов и, по сути, дело вкуса. Но почему то мне кажется, что Redux придется по душе многим, или даже большинству, именно из за своей прямолинейности и простоты.