Комментарии 9
Спасибо за интересный набор примеров! Правда, по некоторым из них остались вопросы:
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 от каждого списка. Может у вас есть какой-нибудь способ на примете?
Sagи из жизни