добавить микрофичи about react-redux-starter-kit

[in19farkt]

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

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

[in19farkt]

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

[krashaen]

чет на мой взгляд сложна, понятно с обычными действиями типа ченжей и тд, но если нужны будут какие то кастомные обработчики, например какая то хитрая валидация, че с этим делать? Да и в целом, не особо ощущал с этим проблем)

[sk1e]

кастомные обработчики, например какая то хитрая валидация, че с этим делать?

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

Да и в целом, не особо ощущал с этим проблем)

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

[DYAPIK]

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

[sk1e]

мне кажется это какой-то еще больший бойлерплэйт, это может добавить излишней сложности, которой потом замучаемся управлять

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

по мне так чем меньше кода тем лучше,

кода как раз меньше будет

не заметил необходимости в делении фич на под фичи

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

[krashaen]

Один такой компонент может подключаться в разные фичи

мы же не юзем вроде бы фичи в других фичах без супер необходимости, а тут мы прощаемся с этим правилом получается?

[DYAPIK]

если они будут иметь стэйт и при этом они довольно маленькие значит выше вероятность того, что их может быть по несколько на странице, в данном случае я так понимаю надо будет делать мультифичность, и разруливать ветки стэйтов одной ФНУ, уже сложно, лучше без мультифич по мне так, просто помню один раз использовал мультиконнектор у нас был для фич, я тогда потел жостко с ним

[sk1e]

если они будут иметь стэйт и при этом они довольно маленькие значит выше вероятность того, что их может быть по несколько на странице, в данном случае я так понимаю надо будет делать мультифичность, и разруливать ветки стэйтов одной ФНУ, уже сложно, лучше без мультифич по мне так, просто помню один раз использовал мультиконнектор у нас был для фич, я тогда потел жостко с ним

Да, истансы микрофич (изменил термин) будут необходимы, но всей работой по доставке всей информации об инстансах куда надо будет заниматься фабрика фич внутри. Ты с этим работать не будешь, для тебя микрофичи предоставят максимальное удобное и простое API (для инстансов фич фабрика, кстати, тоже удобное API тебе предоставит и ты не будешь больше потеть).

Вот пример, у тебя есть 3-х шаговый визард, который состоит из 3 модалок, которые нужно поочерёдно заполнить. Перед тобой стоит задача закрывать одну модалку и открывать следующую при переходе на следующий шаг. Наиболее логично в таких случаях вынести стейт модалок в redux и закрывать/открывать модалки через диспатчи экшенов. Но у тебя появляется проблема в необходимости накатить на фичу 6 однообразных типов экшенов (открытие и закрытие каждой из 3 модалок) , экшен креаторов, добавить обработку 6 типов экшен тайпов в редьюсере, прописать 3 одинаковых начальных состояния, написать 3 селектора. Для всех контейнеров с модалками прокинуть селекторы, заселектить, прокинуть результат isOpen до модалки <Modal isOpen={isOpen} />. Т.е. много однообразной и неинтересной работы.

С микрофичами, например, микрофичей Modal, которая реализует всю работу со стейтом модалки, ты можешь определить стейт микрофич для своей фичи Wizard:

// FeatureState.ts
import * as microfeatures from 'microfeatures';

export interface Microfeatures {
  step1Modal: microfeatures.Modal.State;
  step2Modal: microfeatures.Modal.State;
  step3Modal: microfeatures.Modal.State;
}

импортируешь этот стейт в модуль с описанием микрофич-зависимостей твоей фичи:

// microfeatureDependencies.ts
import * as microfeatures from 'microfeatures';

import { MicrofeatureState } from './FeatureState';

export const dependencies: microfeatures.types.helpers.Dependencies<MicrofeatureState> = {
  [microfeatures.Modal.key]: ['step1Modal', 'step2Modal', 'step3Modal'],
}

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

Создаёшь контейнер в фиче Wizard для модалки на первом шаге:

// Step1Modal.ts
import * as React from 'react';
import block from 'bem-cn';

import Dependencies from '../../Dependencies';

interface Props {
  onClose(): void;
}

const b = block('step-1-modal');

// Dependencies - все зависимости твоей фичи которые прокинула сюда фабрика фич,
// подраздел view содержит только то что может понадобиться во вьюхах
export function Step1Modal({ microfeatures }: Dependencies['view']) {
  return ({ onClose }: Props) => {
    // microfeatures.step1Modal.Component это контейнер микрофичи Modal,
    // он подключён к инстансу своей микрофичи и сам получает нужный ему стейт
    return (
      <microfeatures.step1Modal.Component
        onClose={onClose}
      >
        <div className={b()}>
          step 1 content
        </div>
      </microfeatures.step1Modal.Component>
    );
  }
}

Аналогичным образом определяешь контейнеры с модалками для остальных двух шагов. И определяешь компонент Wizard, который рендерит все 3 шага.

// Wizard.ts
import * as React from 'react';

import Dependencies from '../../Dependencies';

export function Wizard({ microfeatures, components }: Dependencies['view']) {
  // components - компоненты/контейнеры твоей фичи
  return () => {
    const handleStep1ModalClose = React.useCallback(() => {
      // в microfeatures.step1Modal.dispatch хранятся экшен-диспатчеры микрофичи Modal инстанса step1Modal
      microfeatures.step1Modal.dispatch.close();
      microfeatures.step2Modal.dispatch.open();
    }, []);

    const handleStep2ModalClose = React.useCallback(() => {
      microfeatures.step2Modal.dispatch.close();
      microfeatures.step3Modal.dispatch.open();
    }, []);

    const handleStep3ModalClose = React.useCallback(() => {
      microfeatures.step3Modal.dispatch.close();
    }, []);

    // в components хранятся компоненты фичи Wizard
    return (
      <>
        <components.Step1Modal onClose={handleStep1ModalClose} />
        <components.Step2Modal onClose={handleStep2ModalClose} />
        <components.Step3Modal onClose={handleStep3ModalClose} />
      </>
    );
  }
}

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

[sk1e]

Один такой компонент может подключаться в разные фичи

мы же не юзем вроде бы фичи в других фичах без супер необходимости, а тут мы прощаемся с этим правилом получается?

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

[sk1e]

я не очень понял какую задачу/проблему ты тут решаешь

проблема описана в начале. Ты её не заметил или тебе что-то непонятно там?

и зачем миксовать в одну фичу какую-то другую, ради отображения каких-то модалок.

не фичу, а микрофичу. Это другой слой. И не модалок, а любых stateful элементов интерфейса. Текст инпут, чекбокс, радио, селект, таб, expansion panel, вот это всё.

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

Примерно так.

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

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

Микрофичи эксплуатируют эти факты и позволяют повторно использовать этот статичный редакс-слой элемента интерфейса.

[in19farkt]

Чем это решение принципиально отличается от мультиконнекта?

По мне так особо ни чем, за исключением большей сложности, ну и может немного большей гибкости (в текущем пропозале я не вижу возможности использования редакс логики микрофичи вне реакт компонент).

Мультиконнект интуитивно понятен, принцип его работы можно уместить в 2 предложениях. А это решение очень громоздкое, нужно использовать специальные хелперы для сборки и прокидывания микрофич в фичи, на верхнем уровне в слое модулей, вместо того, чтобы просто взять из ContainersProvider'а нужный контейнер, который при желании может выполнять роль хока и отдавать своим чилдренам весь нужный стейт и методы по управлению этим стейтом.

[sk1e]

Чем это решение принципиально отличается от мультиконнекта?

Ну тут практически ничего общего с мультиконнектом. Только возможность работы с множеством инстансов редакс-стейта. Мультиконнект совершенно другое API предоставляет: он не даёт возможность подключения стейта инстанса на отдельную ветку фичи, он не даёт api по выбору инстансов и их составляющих (экшен-диспатчеры, селекторы). Я там пример использования привёл, ты же не сделаешь такое через мультиконнект

По мне так особо ни чем, за исключением большей сложности, ну и может немного большей гибкости

совершенно другие задачи выполняет

в текущем пропозале я не вижу возможности использования редакс логики микрофичи вне реакт компонент

не понял о чём ты. Какая логика и вне каких компонент?

Мультиконнект интуитивно понятен, принцип его работы можно уместить в 2 предложениях.

как уже говорил, мультиконнект никак не решает проблем, которые я тут описал.

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

Хелперы пользователю микрофичи не нужно использовать. Сборкой и прокидыванием будет заниматься фабрика фич в своём коде. Пользователю нужно только декларативно объявить зависимости от микрофич.

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

тут вообще не понял твоих мыслей

[sk1e]

Ну и представь насколько не удобно будет собирать фичу-форму, в которой будут успользоваться 4 инпута-микрофичи.

Микрофичи не для работы с формами, я же писал. Для работы со стейтом форм мы используем другие вещи.

А если сюда еще приплести прокидывание асинхронных фич (в случае если мы не пользуемся ContainersProvider), то вообще жесть получится.

прокидывание куда? В фичу с микрофичами? Оно никак на это не повлияет.

[in19farkt]

он не даёт возможность подключения стейта инстанса на отдельную ветку фичи

Не понимаю зачем мне это может понадобиться, в мультиконнекте ты изолируешь стейт и работу с этим стейтов в отдельную ветку и это правильно. А тут ты получается смешиваешь разную редакс логику в одну ветку стейта. Я вижу тут только проблемы, а преимуществ по мне нет.

Я там пример использования привёл, ты же не сделаешь такое через мультиконнект

Почему не сделаю, очень даже сделаю :) Еще я могу повешать несколько разных контейнеров на одну ветку стейта.

он не даёт api по выбору инстансов и их составляющих (экшен-диспатчеры, селекторы)

<MultiInstanceApiProvider instanceKey="my-feature:microfeature-number-1">
  (({ doSomething, someProp }) => (
    <Component execute={doSomething} someProp={someProp} />
  ))
</MultiInstanceApiProvider>

// MultiInstanceApiProvider - обычный контейнер обёрнутый в мультиконнект

тут вообще не понял твоих мыслей

MultiInstanceApiProvider из примера выше мы можем забиндить в ContainersProvider и все фичи будут иметь к нему доступ

Пользователю нужно только декларативно объявить зависимости от микрофич.

Зачем? Если пользователь может также декларативно забрать мультиинстанс-контейнеры из ContainersProvider :)

не понял о чём ты. Какая логика и вне каких компонент?

о том, что я не могу диспатчить экшены микрофич в сагах фичи.

как уже говорил, мультиконнект никак не решает проблем, которые я тут описал.

Да почему не решает то? все примеры что ты привел, я могу решить с помощью мультиконнекта, и эта логика будет изолирована от фичи, фича ее не будет содержать, она будет пользоваться предоставленным API

[sk1e]

Не понимаю зачем мне это может понадобиться, в мультиконнекте ты изолируешь стейт и работу с этим стейтов в отдельную ветку и это правильно. А тут ты получается смешиваешь разную редакс логику в одну ветку стейта. Я вижу тут только проблемы, а преимуществ по мне нет.

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

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

Есть ещё важное преимущество, я его забыл описать. Клиентами стейта микрофич могут выступать самые разные сущности:

1. Селекторы, саги фичи которая содержит эти микрофичи;
2. Селекторы, саги, компоненты других инстансов этой фичи;
3. Селекторы, саги, компоненты других фич и их инстансов.

С containers provider + multiconnect тебе во-первых нужно будет запоминать, например, какая модалка к какой фиче относится, а во-вторых ты не сможешь предоставишь этот стейт всем клиентам, которые я описал

Почему не сделаю, очень даже сделаю :) Еще я могу повешать несколько разных контейнеров на одну ветку стейта.

ок, сможешь) но API будет значительно вербозным и лимитированным по гибкости и связям.

о том, что я не могу диспатчить экшены микрофич в сагах фичи.

Да, я забыл это описать (описал выше). Экшен тайпы микрофич будут прокидываться в саги. Гибкость будет полная и всем слоям которым сможет что-то понадобиться от микрофич смогут спокойно это достать и воспользоваться.

Да почему не решает то? все примеры что ты привел, я могу решить с помощью мультиконнекта, и эта логика будет изолирована от фичи, фича ее не будет содержать, она будет пользоваться предоставленным API

Выше описал почему такое изолирование является проблемой.

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

[in19farkt]

Куда удобнее когда стейт элементов фичи находится внутри стейта самой фичи

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

Сейчас дополню моменты

Как обновишь описание, пингани. В целом идея интересная, но пока не очень понятны преимущества по сравнению с мультиконнектом.

По поводу саги тоже не понятно, как ты туда динамически прокинешь инстансы подключенных микрофич.

[sk1e]

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

Но фича не может всегда сама управлять своим стейтом. Иногда ей нужно предоставлять такую возможность другим фичам. Тут это явно предоставляется

Единственный плюс который я вижу, это просто удобство дебага, чтобы видно было какой инстанс стейта микрофичи к какой фиче относится.

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

Но это при условии, что редакс логика микрофичи изолирована (внутри ветки фичи) и фича не может напрямую взаимодействовать и вклиниваться в работу редакс логики микрофичи.

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

Обновил текст

[in19farkt]

Но фича не может всегда сама управлять своим стейтом. Иногда ей нужно предоставлять такую возможность другим фичам.

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

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