DZ
кинь имплементацию юз модал?
Size: a a a
2020 July 23
c
а где у тебя стейт находится?
в контексте
c
IA
@sovasergey а ты на сриме сказал “НАШ проползал, который вроде как двигается” (по поводу нативных инстументов для реативности). Вы какой-то прополаз сами двигаете? Или ты про те observalbe которые уже давно обещают?
c
@sovasergey а ты на сриме сказал “НАШ проползал, который вроде как двигается” (по поводу нативных инстументов для реативности). Вы какой-то прополаз сами двигаете? Или ты про те observalbe которые уже давно обещают?
Это я так оговорился)
FT
@sovasergey а ты на сриме сказал “НАШ проползал, который вроде как двигается” (по поводу нативных инстументов для реативности). Вы какой-то прополаз сами двигаете? Или ты про те observalbe которые уже давно обещают?
Мы = фронтенд-заводчане
2020 July 29
BA
const [Modal, { open, close }] = useModal()вот когда я вот точно так же предлагал, все кричали, что хук не должен возвращать компонент
K
Вот, кстати, к вопросу о разделении страниц и фич
на странице несколько крупных блоков: фильтры, график фильтрованных данных, таблица фильтрованных данных
на разных страницах - разные фильтры с разной логикой...
как в таком случае лучше разделять логику?
первое, что приходит в голову - делать каждый такой блок фичей, а в странице просто комбайнить их редьюсеры
если класть все в модель страницы - будут простыни селекторов, редьюсеров и пр....
при этом реально переиспользуемых фич раз-два и обчелся...
на странице несколько крупных блоков: фильтры, график фильтрованных данных, таблица фильтрованных данных
на разных страницах - разные фильтры с разной логикой...
как в таком случае лучше разделять логику?
первое, что приходит в голову - делать каждый такой блок фичей, а в странице просто комбайнить их редьюсеры
если класть все в модель страницы - будут простыни селекторов, редьюсеров и пр....
при этом реально переиспользуемых фич раз-два и обчелся...
c
Вот, кстати, к вопросу о разделении страниц и фич
на странице несколько крупных блоков: фильтры, график фильтрованных данных, таблица фильтрованных данных
на разных страницах - разные фильтры с разной логикой...
как в таком случае лучше разделять логику?
первое, что приходит в голову - делать каждый такой блок фичей, а в странице просто комбайнить их редьюсеры
если класть все в модель страницы - будут простыни селекторов, редьюсеров и пр....
при этом реально переиспользуемых фич раз-два и обчелся...
на странице несколько крупных блоков: фильтры, график фильтрованных данных, таблица фильтрованных данных
на разных страницах - разные фильтры с разной логикой...
как в таком случае лучше разделять логику?
первое, что приходит в голову - делать каждый такой блок фичей, а в странице просто комбайнить их редьюсеры
если класть все в модель страницы - будут простыни селекторов, редьюсеров и пр....
при этом реально переиспользуемых фич раз-два и обчелся...
Обобщить все фильтры в одну фичу. На страницах по разному их конфигурировать
BA
если фильтры различаются, тогда компонент конструктор будет как какашка, даже не ясно, что в итоге лучше
c
если фильтры различаются, тогда компонент конструктор будет как какашка, даже не ясно, что в итоге лучше
Это не будет один компонент
c
Суть обобщения в том, чтобы дать несколько небольших компонентов, из которых можно собрать все, что нужно
BA
а, это фича , а в ней компоненты - фильтры?
BA
ну короче это лучше, чем один делать, мы один сделали и в итоге все в жопу превратилось
K
а как бороться с портянками тех же селекторов? так как разные фильтры имеют совершенно разную логику и результаты
🦜
а как бороться с портянками тех же селекторов? так как разные фильтры имеют совершенно разную логику и результаты
не использовать редакс
K
не использовать редакс
таково требование, после эффектора вообще больно, но увы...
🦜
страдать значит, никто не обещал, что примитивной концепцией будет просто пользоваться. Не хочешь чтобы были ререндеры — умирай в реселекте
K
ну вынеся каждый блок фильтров в отдельную фичу, становится проще
но фичи теряют главный смысл - реюзабельность
но фичи теряют главный смысл - реюзабельность