Отрефакторить FeatureConnector и ContainersProvider

[in19farkt]

Таску делать сначала в mvp-base, после мержить в master

Мысли по поводу того как это должно выглядеть:

У нас в файле FeatureConnector есть хелпер getAsyncContainer (его нужно вынести в отдельный файл), он позволяет из функции loader достать асинхронный контейнер, по сути это HOC, при отрисовке возвращенного им компонента загрузится фичу, фича подключится к стору и отрисуется требуемый контейнер фичи.

Предложение номер раз: фича помимо лоадера может сразу подготовить набор асинхронных контейнеров с помощью хелпера getAsyncContainer, которые мы сможем забирать и отрисовывать не заморачиваясь с оборачиванием. Сами асинхронные контейнеры, возвращаемые хелпером getAsyncContainer, нужно доработать, чтобы они могли принимать пропсы fallback и preloader, думаю не надо объяснять для чего))

FeatureConnector и экспорт лоадеров из асинхронных фич нужно оставить, на случай если где-то потребуются не только контейнеры, но и экшен-креэйторы или селекторы из асинхронной фичи. Редкий кейс, но всё же может понадобиться.

Предложение номер два: ContainersProvider не должен заниматься загрузкой и подключением фич, он должен тупо отдавать нужные контейнеры, которые ранее туда забиндили. И если асинхронные фичи начнут отдавать асинхронные контейнеры, то мы можем сразу их использовать в контейнер провайдере. Сейчас же есть ограничение по использованию контейнер провайдера, он может только с асинхронными фичами, подмешать туда синхронные фичи думаю будет затруднительно, да и ни к чему. Таким образом мы уберем дублирование логики по загрузке фичи и сможем использовать ContainersProvaider независимо от типа фичи.

[in19farkt]

@NikitaRzm @chmnkh @clicktronix че скажете?

[chmnkh]

На первый взгляд прикольная идея, хотя если подумать, то мне кажется это не очень юзабельно. Контейнеры фич в большинстве случаев в модулях используются, в то время как та компонента модуля, что их использует, обычно без этих самых контейнеров вообще ничего из себя не представляет и ее рендерить особо смысла-то и нету. То есть имхо, кейс, когда модуль частично рендерится без контейнеров фич - это вообще редкая штука. В таком случае придется один фиг фича коннект юзать. Короче мне кажется что это нам жизнь усложнит только, потому что придется каждый раз эти экспорты писать (притом что у нас контейнеры еще и через энтри экспортируются, что вообще людей поначалу конфьюзить может) , в то время как вероятность того, что таким образом экспортированные контейнеры будут где-то кроме как в контейнер провайдере использоваться - довольно туманная, на мой взгляд. А синхронные фичи вообще когда юзаются? Ни разу не юзал.

[in19farkt]

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

ну хз) далеко не всегда 'контейнер фичи === раут модуля'. И всегда вместо всего модуля отображать белый экран, из-за того что в 2 местах используются асинхронные контейнеры, мне кажется не очень правильно. FeatureConnector нужен будет только в редких случаях, когда нужно забрать из фичи экшенкреэйтор или селектор, а это один случай возможно из сотни.

---

Короче мне кажется что это нам жизнь усложнит только, потому что придется каждый раз эти экспорты писать

А сейчас мы усложняем себе жизнь собирая все лоадеры и прочее для FeatureConnector'а, ну и сам факт использования FeatureConnector'а тоже само по себе усложнение по сравнению с использованием AsyncContainer'а предоставляемого фичей.

---

А синхронные фичи вообще когда юзаются?

Самый банальный пример: авторизация, прежде чем получить доступ к функционалу приложения нужно всегда авторизоваться, и нет смысла делать эту фичу асинхронной, т.к. она нужна всем юзерам не зависимо от страницы на которую он заходит. Т.е. мы делаем синхронными те фичи, которые всегда и всем юзерам нужны на старте приложения.

[clicktronix]

Со вторым полностью согласен. С первым не до конца чет въехал, как это будет выглядеть. Мы из фичи экспортим контейнеры, обернутые в getAsyncContainer? Потом их просто в модуле импортим и вуаля. А если нужен стейт из фичи то коннектим ее через FeatureConnector? верно?)

[in19farkt]

@clicktronix ага, всё правильно понял)

[clicktronix]

Тогда ништяк) не будем тащить гору шелухи из редакса, если нужен тольлко контейнерё

[chmnkh]

ну хз) далеко не всегда 'контейнер фичи === раут модуля'.

я такого не утверждал :) я говорил, что в большинстве случаев (чисто на моем опыте, не знаю как на других проектах и как канонично) 'множество контейнеров фич + пара оберток над ними, тайтлов и прочей мелочи === раут модуля'

и всегда вместо всего модуля отображать белый экран, из-за того что в 2 местах используются асинхронные контейнеры, мне кажется не очень правильно

где-то да, где-то нет

А на самом деле блин, можно какие-то контейнеры выборочно таким образом экспортить по надобности и все. Не обязательно же экспортить все контейнеры везде и всегда. Это же по сути дополнительная опция, а не полная замена фичаконнекту, где-то зайдет, где-то не зайдет, так что ок.