Да

Но я знаю в каком виде редакс точно нужен

ну во внутренней реализации

главное не спойлерить что он юзается)

Я планирую пройти все его тесты, просто чтобы значть, что фолбэк есть и он работает

сделать как в апполо было

он юзался, но наружу его можно было не выводить

А

Ну типа того, да

Если кто-то будет это юзать и это будет как мидлвара для редукса, то будет больше гемороя из-за неправильного концепутального подхода

Там от самих условий работы для миддлвар столько геморроя что ппц)

Инстансы классов нельзя

Ну а по факту тебе от того редукса ниче и не надо

есть же рх

Выглядит и ощущается примерно как действия ркн

а редукс на рх это 20 строк будут

Кстать, я так понимаю ты там анализировал много чего. В чем беда с cerebraljs ?

))

ужас

Ну да

Он не ориентирован на модульность и вложенность

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

Он как и все пробует решить проблему сверху вниз, забабахать стор и разбирать его

шок-контент

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

боже как сочувствую кому-то у кого это есть в проекте

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

Это чисто из практики понимается, кстати

я хочу LecturerForm разбить в папку

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

что именно

нейминг

мне кажется неудачный

индекс будет экспортить LecturerForm и всё что с ним приходит

у тебя LecturerForm.tsx/LecturerFrom папка / LecturerFormClass.tstc

может можно как-то это понятней назвать

и еще есть

Lecturer.tsx

Lecturers.tsx

у тебя LecturerForm.tsx/LecturerFrom папка / LecturerFormClass.tstc

LecturerForm.tsx удалю, останется только папка

Может как-то

SigleView

ListView

CreateForm

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

потому что рядом с /Lecturers/ будет /Faculties/ и когда я их оба импортирую в другом компоненте мне всё равно придётся назвать LecturerForm и FacultyForm, Lecturer, Faculty и тд

export * as Lecturers from ‘./Lecturerers’;

как вариант

зачем? если у меня будут компоненты LecturerForm и FacultyForm, какая разница с Lecturer.Form и Faculty.Form?

Более понятный нейминг в скопе модуля

Ну точнее более простой

чесно не вижу разницы между Lecturer.Form и Faculty.Form заведомо зная что буду использовать их в общем компоненте

ну вместо LecturerForm в папке лекчурера

можно будет написать просто Form

View

List

он там не используется

я про названия файлов

ну я понял, но в итоге, при импорте будет имя Lecturer.Form и лучше оно собо не станет

при импорте ниче не поменяется

ERROR: S client not available

ну кроме точки

всё равно файл лучше называть по его содержанию, а я хочу именно LecturerForm а не обобщённое название * as Lecturer, тем более это лишает возможности импортировать при тайпинге и добавляет конфликты

LercturerFormSelectTabInput.jsx

не) такого не будет

LecturerFormInputClass.tsx

это компонент, и его части, в нём нет других компонентов

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

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

Я не планирую сторы отдельных компонентов, это стор предметной области

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

соответственно данные из стора в компонент очень часто надо будет передавать в измененном виде

Одним словом, как обычно

Нужна нормальная имплементация методов map и combine и всё

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

Ну как бы у тебя может быть домен и без отображения

Блядь

Вот поэтому и не хотел говорить

Забили

А что думаете насчет такого подхода?

для того чтобы редакс не знал о компонентах нужно просто хранить состояние в виде нормализированных сущностей. Любое приложения каким бы большим оно не было всегда можно разбить на конечное количество типов объектов и связей между ними (один ко многим или многие ко многим). В базе данных типам объектов соответствуют таблицы а в редаксе будут просто отдельные хеши где айдишники соответствуют объекту. Схема состояния примерно такая state = { users: { 0: {id: 0, name: "user0", folders: [0, 1] ...}, 1: {id: 1, name: "user1", ...} ... } projects: { 0: {id: 0, name: "project0", user: 0, tasks: [0, 1] ... }, 1: {id: 0, name: "project1", ... } } tasks: { 0: {id: 0, name: "task0", project: 0, ... }, 1: {id: 0, name: "task0", ... } } }В этом примере мы описали бизнес-логику которая касается хранения данных - юзер может хранить (создавать, обновлять, удалять) проекты, а в проектах хранить задачи. Конкретную логику как создавать, кто может создавать обновлять или удалять и всякие нюансы можно вынести в редюсеры а можно в редюсерах оставить только базовую логику работы с этим состоянием а именно - создать, обновить, удалить а бизнес-логику вынести как раз в контейнеры потому что зачастую именно они вместе с ui определяют все эти нюансы. В итоге получится что редакс будет по сути служить роль базы данных (у него будет только три экшена - create, update, delete, где параметром передается имя таблицы и один или 3 редюсера которые просто создадут обновят или удалят запись в хеше айдишников-объектов) и никак не будет зависеть от компонентов или вообще от отображения - то есть это значит что описав один раз схему данных можно сильно по разному отобразить эту схему в ui (например отображать таски сразу под проектом или на отдельной странице и т.д)

Всё, не было никаких доменов, я понял

((

Последнее чего мне бы сейчас хотелось — это выслушивать споры об античных терминах

ппц... когда люди изобретают базу данных в вебе

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

ппц... когда люди изобретают базу данных в вебе

И что

я вот понимаю еще поддержку этого говна на уровне браузера еще

Да, возникла потребность, да, нету

но когда такое происходит на уровне хешей :))

просто лол

А что думаете насчет такого подхода?

Начинали все с такого