Size: a a a

2020 July 08

M

Maxim Ambrosevich in ☄️ effector
Ruslan 🌀
может передать стор в виде пропса?
дак вопрос же как раз в том, как их динамически создавать)) имея один файл с описанием стора создавать несколько экземпляров)
источник

M

Maxim Ambrosevich in ☄️ effector
🚀🔬 🚀🔬🚀🔬
useStoreMap для вычисления производных данных на основе общего стора

const Table = ({tableId}) => {
 const table = useStoreMap({
   store: tables,
   keys: [tableId],
   fn: tables => tables.find(t => t.id === tableId)
 })
}
спс, посмотрю)
источник

M

Maxim Ambrosevich in ☄️ effector
🚀🔬 🚀🔬🚀🔬
useStoreMap для вычисления производных данных на основе общего стора

const Table = ({tableId}) => {
 const table = useStoreMap({
   store: tables,
   keys: [tableId],
   fn: tables => tables.find(t => t.id === tableId)
 })
}
хм, но стор то все равно один 🤔 и заранее созданный
источник

M

Maxim Ambrosevich in ☄️ effector
или это как раз к тому что писали выше про создание внутри нескольких id
источник

M

Maxim Ambrosevich in ☄️ effector
тогда получается у меня это все должно управляться из родительского компонента?
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
Maxim Ambrosevich
хм, но стор то все равно один 🤔 и заранее созданный
*статически
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
все таблицы вполне можно обрабатывать централизованно
источник

R

Ruslan 🌀 in ☄️ effector
Aleksandr Osipov
Другой вариант загуглить по чату useModel, но я бы не советовал
а useModel можно как-то на fork заменить? (я ещё не вникал в fork)
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
Maxim Ambrosevich
тогда получается у меня это все должно управляться из родительского компонента?
нет
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
🚀🔬 🚀🔬🚀🔬
все таблицы вполне можно обрабатывать централизованно
смысл подхода в том, что данные не начнут неуклонно всплывать наверх когда всё большее количество мест в коде потребует доступа к ним
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
к примеру, когда потребуется встроить перечень таблиц в панель табов приложения, не придётся жонглировать таблицами через самый верхний общий компонент
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
Ruslan 🌀
а useModel можно как-то на fork заменить? (я ещё не вникал в fork)
нет
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
это неверный майндсет, по крайней мере к нему пока что никто не готов
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
пока данные будут загружаться по указке реакт-роутера без вопросов, возможность форкать напостой будет приносить огромный вред: чем это в таком случае лучше useState, приколоченного к конкретной точке в дереве реакта?
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
эффектор это не useState 2.0
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
и в данном случае форк будет использоваться во зло: для того чтобы вкручивать граф в псевдо-дерево неверного майндсета
источник

AO

Aleksandr Osipov in ☄️ effector
Хм а я вот планирую заюзать для разных инстансев логики. Кейс такой есть wysiwig редактор на основе prosemirror и логикой на эффекторе. Редакторов независимых будет неизвестное число, это поля формы. Так вот я через fork как раз планировал
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
если кажется что форк подходит для этого, то я сделаю всё возможное чтобы переубедить в этом
источник

🚀🚀

🚀🔬 🚀🔬🚀🔬... in ☄️ effector
просто попробуй осмыслить одну вещь: добавление форка не избавит тебя от твоих инстансов
источник

AO

Aleksandr Osipov in ☄️ effector
🚀🔬 🚀🔬🚀🔬
если кажется что форк подходит для этого, то я сделаю всё возможное чтобы переубедить в этом
Окей... а как бы ты поступил. По сути редактор это независимый компонент, его конечные пользователи вообще не должны знать о внутренней реализации что-то в том числе о эффекторе
источник