Комментарии 9
НЛО прилетело и опубликовало эту надпись здесь
Reselect, recompose, redux-thunk, normalizr, а вот сага мне не нравится, ну не читабельны эти генераторы.
Когда нужно сделать сложный, динамичный, юзабельный UI используют эти инструменты, которые позволяют сделать разработку проще и потом проще модифицировать. Хотя могут выглядеть сложно.

Спасибо за интересный набор примеров! Правда, по некоторым из них остались вопросы:


WebSockets

Сейчас подписка на сокет активируется при инициализации стора. А что если на текущей странице никто эту подписку не использует? Как оформить сагу так, чтобы веб-сокет открывался по требованию?


Google Places Autocomplete

Сейчас есть безусловная задержка перед запросом. Если в приложении появится возможность изменять query программно (например, кликом по специальным кнопкам), то задержка после клика сделает UI менее отзывчивым.
Как мне кажется, debounce должен жить на уровне конкретного UI-компонента, в котором известно, что события поступают чаще, чем нам нужно. На глобальном уровне это будет только мешать.


Dropdowns Closer

Здесь даже само название как бы намекает, что это должно быть частью UI. В чем смысл держать состояния открытости dropdown в глобальном сторе?


Notifications, Global Event Bus

А в этих примерах вроде все смотрится уместно, вопросов нет.

Спасибо за вопросы.

WebSockets
В таком случае мы можем сделать монтирование саг динамическим с помощью эффектов fork и cancel. Поэтому можно перенести инициализацию сокета в фабричный метод по созданию канала (`createFreshJobsChannel`). Там уже по обстоятельствам — нам может понадобиться сокет как синглтон с ленивой инициализацией, либо уничтожение сокета при уничтожении канала.

Google Places Autocomplete
Вы правы. В таком случае я бы добавил какой-нибудь параметр в action и обернул в условие delay. Можно логику debounce написать в UI, я бы воспользовался HOC или новыми хуками для переиспользования кода. takeLatest оставить всё равно нужно.

Dropdowns Closer
Хотелось что бы это было частью UI. Только не могу придумать как эффективно и в переиспользуемой манере уведомлять все выпадающие списки о том, что им нужно закрыться. Без отдельной подписки на события window от каждого списка. Может у вас есть какой-нибудь способ на примете?
А почему бы и не подписаться на window или document в момент открытия списка?
Звучит действительно хорошо. В скором времени планируем рефакторинг связанного участка кода — обязательно попробую. Спасибо!
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.