AL
норм
Size: a a a
2021 January 27
AL
спасибо всем
EO
По поводу массивов кстати, мне очень зашла эта задачка, я прям профанател ею, когда решал
EO
DB
О, меня permutation как-то остановило, надо будет таки добраться до неё и остальных
EO
О, меня permutation как-то остановило, надо будет таки добраться до неё и остальных
Там оказалось всё просто)
EO
Вернее, не так сложно как я себе представлял
VS
хтось конвертував csv в geojson через visidata?
У мене фейлиться з такою помилкою:
“must save geojson from canvas sheet”
У мене фейлиться з такою помилкою:
“must save geojson from canvas sheet”
VS
Можливо там треба якісь обов’язкові назви для колонок?
VS
Розібрався—насправді візідата може конвертувати лише shapefile в geojson (
IL
Такой вопрос.. теоретический.
Редакс.. саги / санки.
Как вы считаете, что есть более правильным:
1) триггерить екшн, который в свою очередь запускает асинхронную операцию, которая меняет стейт используя другие екшены (то, как это делает редакс сага)
2) триггерить саму асинхронную операцию, которая меняет стейт в процессе дергая екшены (то как санки по умолчанию работают)
3) триггерить саму асинхронную операцию, и руками получив результаты - тыкать их в стор через публичные екшены (грубо говоря то же что и (2), только диспатч отдельно)
Редакс.. саги / санки.
Как вы считаете, что есть более правильным:
1) триггерить екшн, который в свою очередь запускает асинхронную операцию, которая меняет стейт используя другие екшены (то, как это делает редакс сага)
2) триггерить саму асинхронную операцию, которая меняет стейт в процессе дергая екшены (то как санки по умолчанию работают)
3) триггерить саму асинхронную операцию, и руками получив результаты - тыкать их в стор через публичные екшены (грубо говоря то же что и (2), только диспатч отдельно)
IL
Мне в частности вот что интересно.
В редакс тулките предлагается использовать вот такой модный сахарок для санок…
И в общем-то разумно: санка самостоятельная, не завязана на реализацию слайса, и по сути - переиспользуемая.
В редакс тулките предлагается использовать вот такой модный сахарок для санок…
И в общем-то разумно: санка самостоятельная, не завязана на реализацию слайса, и по сути - переиспользуемая.
IL
но там же рядом.. в advanced секции, они сразу же в примере предлагают использовать это вот так.
По сути - жесткая завязка санк-функции на определенный стор, что немного портит картину.
Короче хочу подискутировать и свежих мыслей об этом )
По сути - жесткая завязка санк-функции на определенный стор, что немного портит картину.
Короче хочу подискутировать и свежих мыслей об этом )
AR
Триггерить операцию, обновлять состояние по её результату. Pending состояние асинхронной операции чаще всего можно оставить локальным компоненту, незачем 10 раз обновлять глобальное состояние
IL
Триггерить операцию, обновлять состояние по её результату. Pending состояние асинхронной операции чаще всего можно оставить локальным компоненту, незачем 10 раз обновлять глобальное состояние
то есть идея - перенос максимальной количество “локальной” ответственности - на сам компонент и его состояние, верно?
мне просто интересно кто каких “взглядов” в этом плане придерживается.
мне просто интересно кто каких “взглядов” в этом плане придерживается.
AR
Да, я всегда за локальные решения, на сколько это возможно
IL
Да, я всегда за локальные решения, на сколько это возможно
а если, например, есть состояние, которое в общем-то касается одной страницы (ну и ветки ее компонентов/контейнеров), по сути не есть глобальным состоянием..
решений так много. Я иногда пишу просто свой кастомный хук в котором определяю поведение. Единственная загвоздка, правда, проброс состояния дальше по ветке.. тут тоже решений может быть много: либо тот же контекст, либо какой-нибудь
редакс проще конечно тем, что слой состояния полностью отделен от слоя презентации, и UI просто отображает одно и то же состояние “под разным углом” (с разных страниц/компонентов)
решений так много. Я иногда пишу просто свой кастомный хук в котором определяю поведение. Единственная загвоздка, правда, проброс состояния дальше по ветке.. тут тоже решений может быть много: либо тот же контекст, либо какой-нибудь
constateредакс проще конечно тем, что слой состояния полностью отделен от слоя презентации, и UI просто отображает одно и то же состояние “под разным углом” (с разных страниц/компонентов)
AR
> Единственная загвоздка, правда, проброс состояния дальше по ветке..
Prop drilling можно заменить layout компонентами.
Prop drilling можно заменить layout компонентами.
AR
Например вот так
DB
а если, например, есть состояние, которое в общем-то касается одной страницы (ну и ветки ее компонентов/контейнеров), по сути не есть глобальным состоянием..
решений так много. Я иногда пишу просто свой кастомный хук в котором определяю поведение. Единственная загвоздка, правда, проброс состояния дальше по ветке.. тут тоже решений может быть много: либо тот же контекст, либо какой-нибудь
редакс проще конечно тем, что слой состояния полностью отделен от слоя презентации, и UI просто отображает одно и то же состояние “под разным углом” (с разных страниц/компонентов)
решений так много. Я иногда пишу просто свой кастомный хук в котором определяю поведение. Единственная загвоздка, правда, проброс состояния дальше по ветке.. тут тоже решений может быть много: либо тот же контекст, либо какой-нибудь
constateредакс проще конечно тем, что слой состояния полностью отделен от слоя презентации, и UI просто отображает одно и то же состояние “под разным углом” (с разных страниц/компонентов)
для того чтобы отделить состояние от UI редакс по сути не нужен. Ты можешь брать и изменять стейт в кастом-хуке, в котором хоть useState, хоть useReducer в контексте, хоть из редакса, а в компоненте использовать то же самое апи кастомного хука