Тут вопрос терминологии. Я в этом контексте под «ресурсом» имел в виду «сущность», но, правда, не написал про отличие сущности от «фичи».
Можно сказать, что поиск — это ресурс со своей семантикой, и отличие тут как раз в том, что если какой-нибудь заказ (/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 придется по душе многим, или даже большинству, именно из за своей прямолинейности и простоты.
Ещё 8 правил проектирования API
Можно сказать, что поиск — это ресурс со своей семантикой, и отличие тут как раз в том, что если какой-нибудь заказ (
/orders/{order_id}) — это ресурс-сущность, поиск — это ресурс-фича, так что он всегда доступен.Ещё 8 правил проектирования API
В примере автора же — поиск, который не какой-то конкретный ресурс, которого может не быть. Он есть всегда и всегда успешен, даже если ничего не найдено — «ресурсом» в контексте REST в данном случае будет «результат поиска» (а он может быть и пустым), а не его содержимое. Пользователь/клиент здесь не ошибся. А вот попытка загрузить данные с URI несуществующего ресурса — вполне ошибка, поэтому 404.
Физкультура для программиста, есть ли хороший выход?
Команда энтузиастов выпустила P2P-браузер Beaker 1.0 после двух лет разработки
Касаемо «серверлесса», кстати, всегда было непонятно, нахрена его так называют, когда там вполне себе сервер O_o
Всё дело в Agile — 1: популярные мифы о гибкой разработке
Операторы ?., ?? и |>: будущие возможности JavaScript, которые вам понравятся
Есть варианты
Операторы ?., ?? и |>: будущие возможности JavaScript, которые вам понравятся
Операторы ?., ?? и |>: будущие возможности JavaScript, которые вам понравятся
Restate — или как превратить бревно Redux в дерево
Фронтенд-2017: о самом важном
Ага, особенно «функционального» — в то время как MobX до мозга костей ООП (очень уж полагается на `this`) и предполагает больше императивный стиль, нежели функциональный :)
Фронтенд-2017: о самом важном
Анализ шести веб-фреймворков: плюсы, минусы и особенности выбора
Как библиотека MobX помогает управлять состоянием веб-приложений. Лекция в Яндексе
Ну, MobX вообще не завязан на React технически — его можно хоть с Angular использовать или еще чем-нибудь. Если речь про официальный байндинг mobx-react — то он официально поддерживает React 16. Да ну и там нечему особо сломаться-то.
Angular vs. React vs. Vue: Сравнение 2017
Однако где-то это делать все же надо и тут — вариантов масса и тут VladVR неправ, что действие не может порождать действие — может (оба действия с соответствующим изменением стейта), вполне себе распространенный паттерн «process manager»/«saga», как раз для асинхронности. Везде есть свои нюансы, но совсем без асинхронщины/эффектов — никак в реальном приложении.
Как я перестал любить Angular
Вообще, тренд к «фрактальному стейту» идет — Freactal, Mobx State-Tree, cycle-onionify, Elm Architecture.
N причин, чтобы использовать Create React App
Конечно, Redux — не «rocket science», но за этим вот «выполнить экшены» — куча тех еще компромиссов и ухищрений.
N причин, чтобы использовать Create React App
Введение в React и Redux для бекенд-разработчиков
P.S. Совершенно верно, редьюсеры можно использовать на любом уровне для любого стейта.
Введение в React и Redux для бекенд-разработчиков
UPDATE: Не то, чтобы это хорошо или плохо — с одной стороны, это дает больше гибкости, но с другой — все делают кто во что горазд :) Особенно когда сложность приложения выходит за пределы разумности применения простых вещей вроде redux-thunk (который, вроде как стартовая точка и он же — первый middleware, с которым все сталкиваются).
Введение в React и Redux для бекенд-разработчиков
А кто сказал, что всем нужно именно это? Это просто другой подход. Просто mobx как решение и хранит состояние, и имеет весь инструментарий для его управления. Плюс реактивность MobX, но это немного другая тема.
Redux же очень прост, но, по сути, действительно, умеет только хранить состояние, да и все. Ему нужно что-то, что будет поддерживать весь его (потенциально) навороченный стейт в порядке и согласованности. Причем, с ростом проекта, таких сценариев становится все больше, а они сами становятся все сложнее. Нужна асинхронность, опять же. Отсюда и появляются redux-saga, redux-observable (реактивные «саги»), сам я предпочитаю вообще Cycle.js использовать для подобного рода логики.
Так что, тут просто разница подходов и, по сути, дело вкуса. Но почему то мне кажется, что Redux придется по душе многим, или даже большинству, именно из за своей прямолинейности и простоты.