Всем привет. 5 марта в Санкт-Петербурге пройдет первый митап, который расскажет

подробнее об эффекторе, методиках использования и как же это всё работает под капотом.

ПРОГРАММА

18:00 - 18:10
Сборы, знакомство, общение

18:10 - 18:25
Введение: что такое эффектор, кому он нужен и зачем, краткая история появления, предпосылки и причины

18:30 - 19:10
Прикладное использование: из каких сущностей состоит API, какие проблемы решает, как писать сценарии на реальном примере

19:30 - 20:10
ServerSideRendering: какие сложности с SSR, разбор nextjs/razzle, построение своего решения на effector + react + styled

20:20 - 21:00
We need to go deeper: как всё устроено под капотом, чистые вычисления и барьеры, причем тут графы и как создать сущность

21:10 - 21:50
Секретный доклад: оставайтесь до конца мероприятия!

https://effector.timepad.ru/event/1255181/?utm_refcode=87d18c821c5c113b923a68ce90a247224bc7788f

Пинг

Напоминаю! Осталось несколько дней. Записывайтесь

Завтра закрывается регистрация на митап! Осталось не так много мест!

На всякий случай напоминаю почему Effector вообще появился и какие у него плюсы: — децентрализованность, декларативность, эффективность. требовался инструмент, позволяющий управлять данными в сложных приложениях без опасности раздуть монолитный центральный стор, с явным control flow, нормальной типизацией и емким апи — сторы для приложения должны быть лёгкими, насколько это возможно — не должна пугать мысль о том, что нужно добавить ещё один стор для конкретных нужд — сторы должны свободно совмещаться — идея в том, что данные, которые потребуются приложению, можно распределить статически, заранее показав как данные будут преобразоваться во время работы приложения — принцип работы должен by design исключать необходимость в reselect, оповещая об изменениях только тех, кому они необходимы. это позволяет не задумываться о том, что у тебя будет триггериться всё приложение если ты захочешь вынести стейт модалки из реакта. по совместительству это означает что приложения избавлены от проблем с перфомансом, возникшим у react-redux при переходе на контекст — возможность, место, и способ вынести любую требуемую бизнес-логику из view, максимально упрощая компоненты — независимость от спорных концепций — никаких декораторов, никаких зависимостей от реакта/rxjs либо необходимости юзать классы или прокси — ничего из этого не требуется для управления состоянием приложения и поэтому апи библиотеки использует только функции и простые js объекты — предсказуемость апи. небольшое число базовых принципов переиспользуются в различных кейсах, снижая нагрузку на юзера и повышая узнаваемость. зная как работает .watch в эвентах, можно догадаться, что делает функция .watch у стора — приложение строится из комбинации базовых элементов и возможности строить новые. нет никакого смысла стремиться выдать всё за стрим, за редьюсер или за обсервабл, в приложении требуются они все, и библиотека предлагает решение чтобы управлять структурой данных, а не скрывать её

https://youtu.be/IacUIo9fXhI