NS
Это просто пример с
TODO такой? Там действительно для UI удобнее так итерироваться по массивуSize: a a a
2020 May 15
S
Еще прям ласт вопрос, а почему в примерах чаще всего сущности хранят в массивах?
Потому что прямая аналогия с реальными данным, нормализация это отдельный паттерн, которым может усложнять понимание
NS
Спасибо за ответы
a
Если
Entity, а точнее их количество - известно до получения данных - то это атомы, если нет, т.е. их количество динамически меняется - то это производные от атомов session и collectionsТ.е. так - если данные даны заранее (в коде) - создаем из них атомы и через
Если данные приходят во время работы приложения - создаем верхнеуровневые атомы и через
combine объединяем.Если данные приходят во время работы приложения - создаем верхнеуровневые атомы и через
map вытаскиваем то что нужно там где нужноa
И тут захотелось combine переименовать в join 🤔
2020 May 18
a
Переслано от Ryzhikov Nikolay
теперь тоже как люди сможете с состоянием работать
a
Переслано от Ryzhikov Nikolay
дальше нужен герой который re-frame портанет
a
Вы уже пробовали новый state manager? Как он в сравнении с Reatom - что похоже, что нет? Плюсы/минусы? https://recoiljs.org/docs/introduction/getting-started
В прошлый раз я потратил 2 минуты на обзор рекоил, сейчас 10. Выводы:
- разделение узлов на атомы и селекторы нужно редко и рекоил избыточно это пропагандирует.
- то что работа с асинхронщиной типа build-in - это прям хорошо, но завязка в этом на реакт - не очень.
- утилы из коробки тоже - хорошо, но очень смущает бандлсайз, какой-то он запредельный для указанного функционала.
- ну и я уже говорил, возможность писать напрямую в атомы выглядит конечно, удобно, но это плохо скейлится и тяжело дебажится в долгосрочной перспективе.
В общем и целом рабочий вариант, хорошая эволюция, но все ещё не революция. Не подходит для маленьких и больших проектов - для средних норм.
С моей точки зрения реатом будет проще, гибче и надёжнее, но нужно будет выбрать как с асинхронностью работать.
- разделение узлов на атомы и селекторы нужно редко и рекоил избыточно это пропагандирует.
- то что работа с асинхронщиной типа build-in - это прям хорошо, но завязка в этом на реакт - не очень.
- утилы из коробки тоже - хорошо, но очень смущает бандлсайз, какой-то он запредельный для указанного функционала.
- ну и я уже говорил, возможность писать напрямую в атомы выглядит конечно, удобно, но это плохо скейлится и тяжело дебажится в долгосрочной перспективе.
В общем и целом рабочий вариант, хорошая эволюция, но все ещё не революция. Не подходит для маленьких и больших проектов - для средних норм.
С моей точки зрения реатом будет проще, гибче и надёжнее, но нужно будет выбрать как с асинхронностью работать.
PM
Спасибо, интересно!
NS
export const setDisposableCartId = declareAction('disposableCartId');
———
store.dispatch(setDisposableCartId('cart1'));В вызове TS говорит, что ждал 0 аргументов, что я делаю не так? Разве обязательно реакции указывать?
NS
А, тип дженерик:
export const setDisposableCartId = declareAction<string, 'setDisposableCartId'>(['setDisposableCartId']);
a
export const setDisposableCartId = declareAction('disposableCartId');
———
store.dispatch(setDisposableCartId('cart1'));В вызове TS говорит, что ждал 0 аргументов, что я делаю не так? Разве обязательно реакции указывать?
Обязательно тип пайлоада указывать, если он планирует передаваться
NS
А как
combine работает, если у меня у несколько атомов — это объекты, у которых есть ключ collections?NS
У меня на каждую коллекцию свой атом сейчас есть, хочу закомбайнить их
NS
collections: {
entity1: entity1Atom,
entity2: entity2Atom,
}NS
Хотя можно и плоско, это даже скорее пропогандируется библиотекой?
a
Можешь код показать?
н#
Переслано от Ryzhikov Nikolay
ловите clojure goods в js завезли https://github.com/artalar/reatom
в чем состоит шутка? :)
a
в чем состоит шутка? :)
Это не шутка, а мнение уважаемого человека))