react-redux-starter-kit
react-redux-starter-kit copied to clipboard
fullstack-development
Отрефакторить FeatureConnector и ContainersProvider
Таску делать сначала в mvp-base, после мержить в master
Мысли по поводу того как это должно выглядеть:
У нас в файле FeatureConnector есть хелпер getAsyncContainer (его нужно вынести в отдельный файл), он позволяет из функции loader достать асинхронный контейнер, по сути это HOC, при отрисовке возвращенного им компонента загрузится фичу, фича подключится к стору и отрисуется требуемый контейнер фичи.
Предложение номер раз: фича помимо лоадера может сразу подготовить набор асинхронных контейнеров с помощью хелпера getAsyncContainer, которые мы сможем забирать и отрисовывать не заморачиваясь с оборачиванием. Сами асинхронные контейнеры, возвращаемые хелпером getAsyncContainer, нужно доработать, чтобы они могли принимать пропсы fallback и preloader, думаю не надо объяснять для чего))
FeatureConnector и экспорт лоадеров из асинхронных фич нужно оставить, на случай если где-то потребуются не только контейнеры, но и экшен-креэйторы или селекторы из асинхронной фичи. Редкий кейс, но всё же может понадобиться.
Предложение номер два: ContainersProvider не должен заниматься загрузкой и подключением фич, он должен тупо отдавать нужные контейнеры, которые ранее туда забиндили. И если асинхронные фичи начнут отдавать асинхронные контейнеры, то мы можем сразу их использовать в контейнер провайдере. Сейчас же есть ограничение по использованию контейнер провайдера, он может только с асинхронными фичами, подмешать туда синхронные фичи думаю будет затруднительно, да и ни к чему. Таким образом мы уберем дублирование логики по загрузке фичи и сможем использовать ContainersProvaider независимо от типа фичи.
На первый взгляд прикольная идея, хотя если подумать, то мне кажется это не очень юзабельно. Контейнеры фич в большинстве случаев в модулях используются, в то время как та компонента модуля, что их использует, обычно без этих самых контейнеров вообще ничего из себя не представляет и ее рендерить особо смысла-то и нету. То есть имхо, кейс, когда модуль частично рендерится без контейнеров фич - это вообще редкая штука. В таком случае придется один фиг фича коннект юзать. Короче мне кажется что это нам жизнь усложнит только, потому что придется каждый раз эти экспорты писать (притом что у нас контейнеры еще и через энтри экспортируются, что вообще людей поначалу конфьюзить может) , в то время как вероятность того, что таким образом экспортированные контейнеры будут где-то кроме как в контейнер провайдере использоваться - довольно туманная, на мой взгляд. А синхронные фичи вообще когда юзаются? Ни разу не юзал.
Контейнеры фич в большинстве случаев в модулях используются, в то время как та компонента модуля, что их использует, обычно без этих самых контейнеров вообще ничего из себя не представляет и ее рендерить особо смысла-то и нету.
ну хз) далеко не всегда 'контейнер фичи === раут модуля'. И всегда вместо всего модуля отображать белый экран, из-за того что в 2 местах используются асинхронные контейнеры, мне кажется не очень правильно. FeatureConnector нужен будет только в редких случаях, когда нужно забрать из фичи экшенкреэйтор или селектор, а это один случай возможно из сотни.
Короче мне кажется что это нам жизнь усложнит только, потому что придется каждый раз эти экспорты писать
А сейчас мы усложняем себе жизнь собирая все лоадеры и прочее для FeatureConnector'а, ну и сам факт использования FeatureConnector'а тоже само по себе усложнение по сравнению с использованием AsyncContainer'а предоставляемого фичей.
А синхронные фичи вообще когда юзаются?
Самый банальный пример: авторизация, прежде чем получить доступ к функционалу приложения нужно всегда авторизоваться, и нет смысла делать эту фичу асинхронной, т.к. она нужна всем юзерам не зависимо от страницы на которую он заходит. Т.е. мы делаем синхронными те фичи, которые всегда и всем юзерам нужны на старте приложения.
Со вторым полностью согласен. С первым не до конца чет въехал, как это будет выглядеть. Мы из фичи экспортим контейнеры, обернутые в getAsyncContainer? Потом их просто в модуле импортим и вуаля. А если нужен стейт из фичи то коннектим ее через FeatureConnector? верно?)
Тогда ништяк) не будем тащить гору шелухи из редакса, если нужен тольлко контейнерё
ну хз) далеко не всегда 'контейнер фичи === раут модуля'.
я такого не утверждал :) я говорил, что в большинстве случаев (чисто на моем опыте, не знаю как на других проектах и как канонично) 'множество контейнеров фич + пара оберток над ними, тайтлов и прочей мелочи === раут модуля'
и всегда вместо всего модуля отображать белый экран, из-за того что в 2 местах используются асинхронные контейнеры, мне кажется не очень правильно
где-то да, где-то нет
А на самом деле блин, можно какие-то контейнеры выборочно таким образом экспортить по надобности и все. Не обязательно же экспортить все контейнеры везде и всегда. Это же по сути дополнительная опция, а не полная замена фичаконнекту, где-то зайдет, где-то не зайдет, так что ок.