А до осмысления?)

а к фреймворку привязано?

Я ещё не готов, это не столько код сколько концепция и я в ней ещё не всё что надо продумал

А схематично можешь обозначить идею?

А схематично можешь обозначить идею?

Дык в этом проблем нет.

Я просто только присоединился к разговору)

Я примерно представил как оно работает. Однако только в реакте.

Есть хок, который регистрирует состояние в редакс и убирает за собой.

Это не столько идея (одна) сколько набор патчей к изначальной концепции) С учетом того что у нас сейчас всё типизировано

Можете рассказать или кинуть в меня сообщением?

я представил без реакта

с реактом у меня тяжелая нелюбовь

Есть хок, который регистрирует состояние в редакс и убирает за собой.

Нет, вообще не привязано к реакту изначально

Нет, вообще не привязано к реакту изначально

Круто! Буду ждать релиза!

Нет, вообще не привязано к реакту изначально

Хм... Тогда я не могу понять как узнавать то, что тебе нужна та или иная секция в редакс.

роутер

Ага

декораторы

роутер

Что роутер?

Короче исходим из принципа минимальной магии

Что роутер?

Загружать редьюсер в зависимости от роута?

Загружать редьюсер в зависимости от роута?

Так ты только часть сценариев покрываешь.

У меня в приложении вообще роутов нет, к примеру.

Да, no silver bullet

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

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

Но там просто. Когда грузится компонент, то он обёрнут хоком, на котором в componentWillMount и componentWillUnmount добавляется редьюсер и прогоняется экшен инициализации.

А так - каждому нужно своё условие добавления-удаления редьюсера делать.

Удаления редьюсеров нет, это в дефолтном виде приносит только проблемы

Удаления редьюсеров нет, это в дефолтном виде приносит только проблемы

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

Но там просто. Когда грузится компонент, то он обёрнут хоком, на котором в componentWillMount и componentWillUnmount добавляется редьюсер и прогоняется экшен инициализации.

1 редьюсер на компонент? Оо

Короче если схематично: Экшны руками создавать не требуется, так как есть createAction(description: string) Тип руками тоже не создаём, и не юзаем и вообще особо напрямую не используем То есть везде у нас есть в первую очередь данные, они отправляются в actionCreator и они же читаются редьюсерами Экшн типизируется не строками а данными которые они принимают при создании. Это ключевая точка, единственное место в коде где мы напрямую указываем, какие типы будем передавать

1 редьюсер на компонент? Оо

Не обязательно один.

Потому что ты n редьюсеров всегда можешь пред=вратить в один.

Далее на основе этих экшнов создаются редьюсеры. Я использую redux-act но фактически от него только обёртка осталась

Как можно заметить, все редюсеры без типов вообще

Тем не менее полностью типизированные :)

Фича в том, что описав экшны на основе payload мы получаем возможность выводить тип сразу и их и редьюсеров

createReducer({} — это потому что в акте в первом аргументе reducer map, который нам больше не нужен. Во втором аргументе — defaults .on — это поочерёдное добавление экшнов, на которые будет реагировать данный редьюсер

off)

В .on в первом аргументе как и везде в других местах передаётся экшн-креатор, который теперь сам по себе символизирует тип экшна

off)

Вот перепишу act, выпилю ваще ? Реально пока нет unload редьюсеров — он ни зачем вообще

Далее улучшения — скоупы

Блин, а это офигенная идея.

это в каком проекте?

это в каком проекте?

Пока в закрытом, скоро портирую в telegram-mtproto

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

Никак, я вижу основания об этом пока не думать, так как там есть тесная связь с более глубокими концепциями)

Никак, я вижу основания об этом пока не думать, так как там есть тесная связь с более глубокими концепциями)

Да, просто я не вижу тогда смысла подключать динамически редьюсеры. Зачем это надо?

code splitting

Непосредственно связано со следующей вещью о которой я хочу рассказать)

code splitting

Я не думаю, что у меня и у тебя одинаковое понятие этой вещи. Что ты имеешь ввиду?

Я не думаю, что у меня и у тебя одинаковое понятие этой вещи. Что ты имеешь ввиду?

лол

lazy подгрузку чанков

Ок, понял.

то есть по роуту

А без роутов никак?)

На самом деле это функция importReducer которую ты вызываешь перед тем как у тебя появляется код который использует данные редьюсеры

В нашем случае это роуты, потому что scope

Далее улучшения — скоупы

Обнаружив у себя кучу экшнов вида user/auth/logout, я сделал вывод, что скоупы уже существуют как факт и можно только сделать их объявление проще

import { actionScope } from 'Store' const authAction = actionScope('auth') const loginAction = authAction.childrenScope('login') const doLogin: Action<{ user: string, pass: string }> = loginAction('doLogin') В дев тулсах при этом будет экшн [xx] auth/login/doLogin то есть это чисто вопрос удобства

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

То есть если мы делаем допустим страницу регистрации, то можем положить папку state прямо в директорию со страницей регистрации (подразумеваю, что используется атомик или просто что-либо кроме деления components/containers)

И грузить редьюсер по требованию, бонусом имеем экшны в шаговой доступности от компонентов и простоту рефакторинга — сразу понятно кто и где будет юзать эти экшны и эти данные в childReducer То есть получается такой сабстейт без проблем сабстейта так как у нас всё по прежнему — единый стор, но рабитый не физически а логически

ERROR: S client not available

Короче я чот подустал (это ещё не всё), кому там интересно было)

@iRbisaDm @thekiba

Прости, я рублю оливье, пристану к тебе попозже

Понял. У нас похожим способом сделано за исключением того, что единого стора нет

Да я вот тоже понял что продолжать стоит числа так второго)

ваше здоровье!

накатим

еще вроде и рано, но почему бы и нет

накатим)

Я еще в поезде. Сойду через пол часа, остальные поедут в новый год в вагоне. Четырех парней перебравших с водочкой уже сняли.

Сурово :)

В целом все мирно

Накатим!

лол

Вопрос не по теме. А кто как приваты делает недоступными в итоговой сборке?

За типизацию!

Боже, храни типизацию!

За типизацию!

?

Привет выжившим!

✋

доброе утро

утро да, такое

Всем привет. Только начинаю вникать в ts, можно ли как-то заставить работать 3й случай? - https://clck.ru/CS7PU

applyMods({ size: 's', theme: 'normal', });

да, это 1 случай

мне нужно 3й

as SomeProps

as SomeProps

это тоже самое что и второй)

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

String enums как вариант