TG
да не в абстракциях дела. а в банальном уменьшении кода.
Size: a a a
2021 June 13
TG
и скорости
ei
Банальное уменьшение кода это бред
ei
Код стоит убирать когда он не нужен
ei
Я например пишу больше кода, если из-за этого решение выглядит понятнее и прозрачнее
TG
ну смотри. логика конечно варьируется. но 80% может быть одинаковой. и вопрос в том как эти 80% не писать много раз подряд
TG
ну вот с этим согласен
ei
Чем с какими-то нестабильными хитростями завязанными на реализации и на конкретном кейсе
АХ
Разбить на какую нибудь композицию компонентов
ei
По сути ему не нравится что в обертке надо писать useStore) Как раз штука которую решает рефлект
ei
Ну может еще эффект
TG
ну вот у меня 4 одинаковые таблицы. я конечно могу сидеть копипастить все эти связи юнитов, создавать эффекты, сторы, евенты под каждую таблицу.
но проще же сделать 1 компонент, 1 фабрику.
и прокинуть в этот 1 компоннет, 4 экземпляра созданные фабрикой.
и если говорить о той же простоте. вкинуть в 100 строк кода проще чем в 400
но проще же сделать 1 компонент, 1 фабрику.
и прокинуть в этот 1 компоннет, 4 экземпляра созданные фабрикой.
и если говорить о той же простоте. вкинуть в 100 строк кода проще чем в 400
TG
верно мыслишь, но чуть нужно дополнить.
1. не нравиться что надо в ебертке писать useStore
2. однотипные useStore будут друг другу мешать
3. объем кода у бертки увеличивается
4. на каждый useStore мы получаем некие значения, которые надо прокинуть в компонет
5. за пунктом 4 следует то что надо каждое значение протипизировать и принять в компоненте
а можно прокинуть один единственный объект и дело с концом)
1. не нравиться что надо в ебертке писать useStore
2. однотипные useStore будут друг другу мешать
3. объем кода у бертки увеличивается
4. на каждый useStore мы получаем некие значения, которые надо прокинуть в компонет
5. за пунктом 4 следует то что надо каждое значение протипизировать и принять в компоненте
а можно прокинуть один единственный объект и дело с концом)
TG
1-5 пункты можно вынести в хук и сделать условный useTable который уже принимает в себя юниты.
но тоже каждый юз кейс таблицы, создает алгоритм шагов что бы переиспользовать код. легко запутаться
но тоже каждый юз кейс таблицы, создает алгоритм шагов что бы переиспользовать код. легко запутаться
АХ
const UserTableA = reflect({
view: Table,
bind: {
...moduleFabric(paramsA)
}
})
Как насчёт такого варианта?
АХ
Все эти пункты, как мне кажется, тут покрыты
ei
Вот-вот, то же самое почти писал)
ei
const Table = () => { ... }
const UserTable = reflect({
view: Table,
bind: {
items: $users,
status: $usersLoadingStatus,
load: (params) => fxLoadUsers(params)
}
})TG
вариант хороший, если удастся донести до остальных подключение reflect в проект.
но я так же рассматриваю альтернативы без рефлекта)
но я так же рассматриваю альтернативы без рефлекта)
ei
Только думаю тупо спредить туда модуль не оч затея, там всякие эффекты и прочее, от этого лучше абстрагироваться