Разберем пятый тейк про переиспользования юнитов и связей.

несмотря на то что мы ограничены и в создании, и в уничтожении сущностей, мы не можем их переиспользовать. Разве это не звучит контринтуитивно?

Переиспользование невозможно из-за того, что все сущности статически связаны друг с другоми и попытка их использовать в другом контексте приведёт к тому, что все прежние зависимости неминуемо тоже обновятся.

Да, это так. Скорее всего это не интуитивно.
Можно представить это себе так:

export const foo = { value: 1 }

Любой может импортировать этот объект и менять его значение. Это не глобальный объект, так как его нет в глобальном неймспейсе, чтобы его менять, нужно сначала получить ссылку.

Решением может быть создание экземпляров логики через функции с логикой на effector внутри:

export function createUploader($name: Store<string>) {
  const uploadSelected = createEvent<File>();
  const uploadStartClicked = createEvent();

  // ...
  
  sample({
    clock: uploadSelected,
    target: attachmentNewFx,
  });

  return { uploadSelected, uploadStartClicked };
}

Вызываем эти функции в корне модулей, или в других подобных функциях и вот, есть цепочки событий, полностью отделенные от слоя представления, который вычисляется из данных напрямую.

Пятый тейк попадает в Справедливо. Не всегда создание инстансов фабрик решает вопрос удобнее, нежели классы или даже грустная динамика на компонентах React.

Шестой тейк, который привлек мое внимание

Во-первых, благодаря «декларативности» семплов их порядок как будто бы становится неважным (хотя на самом деле он имеет значение). Это приводит к тому, что попытка переписать на них простую линейную логику может привести к появлению больших модулей, состоящих из мелких семплов.

Среди них очень сложно понять, где начало и конец логического блока, особенно когда ты видишь этот код впервые. Тут легко попасть в ловушку: писать такие семплы может быть просто и даже приятно, но читать чужой код на семплах может оказаться сильно сложнее. В нашем коде встречаются модули, состоящие из нескольких десятков семплов, которые понимает только их автор.

Тут сложно не согласиться. Для написания кода требуется определенная культура. Как и в случае MobX, требуется понимание как выстраивать код наглядно и понятно.

В случае React hooks этот тейк имеет еще больший вес. Так как сложную логику легко написать на хуках не выйдет.

Шестой тейк оцениваю как Справедливый. Сейчас документация не рассказывает как удачно структурировать приложение, декомпозировать логику и наглядно оформлять файлы исходников.

Effector как и любой инструмент требует обучения, хотя бы минимального.
Тогда как, большинство других СТМ, вроде Zustand, recoil, nanostores, реализуют очень простые паттерны, привычные всем вокруг. К сожалению, setState и строковые ключи очень плохо масштабируются с ростом приложения и команды, приходится что-то придумывать и костылять поверх.

Любопытный взляд на ограничения инструментария в седьмом тейке.

возможность с помощью семпла обновить любую другую сущность из любого места усложняет определение зависимостей. Другие менеджеры состояния предлагают описывать зависимости при создании сущности, поэтому, чтобы определить список зависимостей элемента, достаточно посмотреть его определение.

Семпл же позволяет описывать сущности и зависимости отдельно, в том числе добавить зависимости позже и в другом месте. Это значит, что информация о зависимостях может быть размазана по всему коду нашего приложения.

Инверсия зависимостей появилась по той же причине, что и sample.
Для добавления новых возможностей приходится модифицировать слишком много кода. Вместо работы через интерфейсы, разработчики вынуждены добавлять новые зависимости прямо в код существующих сущностей.

Пускай седьмой тейк будет в категории Отчасти Справедливо. Да, зависимости описываются менее явно, не через вызовы методов, а через набор импортов в модуле.

Это тот выбор, который делает команда, либо мы идем через прокидывание зависимостей при создании и подключаем DI-контейнер или же страдаем от аналога props-drilling на классах.
Либо зависимостями управляет стандартная система модулей в вашем проекте.

С другой стороны, в чате @effector_ru есть примеры интеграции effector с DI-контейнерами вроде Inversify.
В случае без SSR, можно выполнять очень необычные выкрутасы с юнитами effector.
Для SSR и мейнстримного подхода в effector есть готовые инструменты, а для подхода на классах почти нет.

Я бы сказал, что в effector данные и их перетекание важнее, чем абстракные сущности. Сущности могут быть построены через фабрики/классы/динамику поверх данных и реактивных потоков.

А вот от восьмого тейка меня покорежило:

Тут я пытаюсь сказать, что можно знать инструмент, а можно считать, что знаешь. Когда инструмент простой, в нём мало подводных камней априори. Но если он сложный, если в нём есть несколько способов сделать одно и то же, то было бы неплохо, чтобы инструмент работал ожидаемо.

Давайте начнем с того, что большая часть разработчиков не знает как работает браузер и это не мешает им думать, что они знают и зарабатывать на этом деньги. Более того, я сам не знаю до конца как именно он работает, технологии уже стали слишком сложными.

Да, когда инструмент простой, все может выглядеть просто. Но не всегда нужны только простые инструменты. Иначе у нас никогда не появилось бы сложных технологий.

А во вторых, ожидать от инструмента что-то это ошибка новичка. Потому что ожидания строятся на основе предыдущего опыта, а если тебе встречается что-то, незнакомое, то тут неоправданные ожидания и бьют по лицу со всей силы.
К тому же, у всех людей разный опыт и ожидания разные.

Не знаю, как вы, а лично я до того, как прочитал соответствующий раздел в документации, ожидал, что подписки выполняются в порядке объявления.

Восьмой тейк попадает в категорию Кринж. Это не категория Несправедливо, потому что документация не рассказывает как прочувствовать инструмент. По крайней мере пока

Вот этот девятый тейк очень справделив.

Что примечательно, .on ведет себя иначе, повышая приоритет вычислениям.

@monada_kedavra заметил, что подобное поведение должно быть исправлено.

Но дальше автор утверждает, что Pull-стратегия лучше Push.

В случае Effector мы эти преимущества не получаем, потому что библиотека использует самую простую стратегию обновления и самый тривиальный алгоритм обхода графа.

Стратегия обхода в effector вообще построена на нескольких очередях обновления с разными приоритетами. Так что утверждение выше просто ложно.

Не знаю, с чем это связано, возможно с недостатком тестов на поведение effector. Автор начал очень хорошо, но проделав пару простых проверок, дальше не пошел.

Десятый тейк справедлив и обоснован, но рассматривается с неправильного угла.

В js тоже можно сделать бесконечный цикл вешающий вкладку.
Автор требует от инструмента очень больших ограничений накладываемых на код.

Effector же дает определенную свободу в описании сценариев выполнения. Таким образом развязывая программисту руки в реактивном коде.

Я бы сказал, что effector это реактивная прослойка поверх js. Если хочется жутко ограниченную систему, которая требует сложных систем, вроде DI и IoT-контейнеров, то это не сюда; по крайней мере пока.

А вот остальные тейки разбирать как-то даже влом.

Написав на несколько строк кода больше, мы получили логику, которая:

- может быть переиспользована с разными входными данными, то есть на странице может быть одновременно несколько независимых компонентов поста, каждый в своём состоянии;

Да, но SSR и гидратация состояния вышла из чата.
Только такой простой случай и будет работать хорошо.

А если хук зависит от кучи других данных, придется
либо а) поднимать состояние выше, что уже выглядит не так красиво и вызывает props-drilling,
либо б) использовать контекст и перерендеривать кучу VDOM-деревьев на каждый чих, что вызывает просадки перфа,
либо в) выносить состояние из компонентов и получать все те же проблемы, о которых статья.

- может быть с лёгкостью модифицирована благодаря тому, что весь логически связанный код находится в одном месте и у нас нет ограничений на использование значений переменных. Например, мы добавили отмену устаревших запросов с помощью AbortController (напишите в комментариях, как то же самое сделать в коде на Effector);

Да, всё так, но только до тех пор, пока кейс простой. При подписке на любой источник данных, сложность кода взлетает сразу же. И жить без СТМ или query/swr уже почти нереально.

- работает чуть более эффективно, потому что вся инициализация и загрузка данных происходят только тогда, когда они действительно нужны;

Работает эффективно? В каких случаях? Ведь при запуске фичи, придется сделать кучу работы по инициализации всей фичи.

- проще читается и понимается большинством JS-разработчиков, которые видят её впервые, благодаря тому, что код более линейный и не требует знания Effector.

Отчасти да, но все опять упирается в простейший пример.
А ведь в приложениях не простой код и этой сложностью хочется как-то управлять.
Ребята из бигтеха наверняка должны это знать.

Мой наброс сюда:
Как эту логику, намертво завязанную на версию реакта и тулинга вокруг тестировать?

Или тесты будут падать при обновлении рендерилки в html? Хоть тест и никак не связан с react, но он будет падать из-за совершенно посторонних проблем.

И это я привожу только самый яркий пример.

ИТОГИ

Здесь мои супер субъективные набросы. Обратите внимание, что я высказываю свою точку зрения и могу ошибаться на счет других людей.

1. Тейки про производительность стоит десять раз проверять.
Автор сделал выводы о производительности и внутреннем устройстве библиотеки на основе поверхностного исследования и пишет статью об этом как эксперт.
Это грустно, но что поделать.

2. Документация сейчас действительно не объясняет ценность инструмента и как им глобально пользоваться.
Это минус, которым сейчас занимается effector core team.
Держим в уме.

3. Тейки про простоту кода основаны на сравнении простых примеров, хотя в самом начале автор пишет, что документация рассматривает тривиальные, далёкие от реальности примеры вроде счётчика.
Почему не показать как надо? Зачем повторять в статье такие же тривиальные примеры?

С разделом выводы я согласен.
Читать статью стоит хладнокровно, критично, объективно и взвешенно.

Это негативный опыт, причиной которого стал в основном недостаток обучающих гайдов и желания разбираться.
Он ценен, во первых критическим взглядом на статьи, даже от гигантов вроде VK.
А во вторых, подсвечивая слабые места и как их можно исправить.

Как помочь?
1) Прийти на effector.dev, почитать всё что есть, предложить изменения через Edit this page.
2) Открыть issues, вычитать то, что вы понимаете, вписать своё мнение, предложить решение, открыть PullRequest.
3) Создать новый issue, которого еще не было, но который важно обсудить.

Спасибо всем, кто вкладывается в создание и улучшения effector.
🧡

Я уже много лет пользуюсь nvm для манипуляций версиями Node.js.

Хоть меня и все устраивает в nvm, все равно поглядываю на альтернативы.
fnm вроде неплохой, но я не нашел официального экшена для Github Workflows.

А у Volta экспериментальная поддержка pnpm, которым я пользуюсь почти всегда.
https://docs.volta.sh/advanced/pnpm

Кто-то пользуется Volta+pnpm? Как опыт?

Ждем?

Рассматривал логи с лендинга frontend.vision и заметил странный Yandex Browser

А также скрипт, которого в коде лендинга нет

Кто-то уже пользовался GitHub Models?

Что на счет новых моделей? Тестируем?

К слову, про новую «думающую» модель

Вот непонятно, есть ли смысл отказываться от Rectangle app.

Я обычно пользуюсь tig, но тут по советам из комментов решил попробовать lazygit.

Открываю софтину, а там you rock

🗿

У кого есть инвайт в Deadlock?

Github теперь отображает префиксы, вроде test: или feature: в названии коммита в виде лейблов!

Тем временем, после появления дженериков в Go, потихонечку добавляют и все остальные фичи из Rust.

https://t.me/crossjoin/361

Давайте повангуем в комментариях: с какой версии Go приблизится к Rust, по сложности синтаксиса и количеству фич?

Я думаю, где-то к 1.70, Go уже не будет "простым" языком, а чисто типа Rust, только с GC и компилится побыстрее.

Поэтому прямо сегодня выбираю для себя язык сегодняшнего и будущего дня — Zig(нет).

Тем временем, Winamp открыл исходники своей легендарной версии под Windows.

Написано на плюсах, можно скомпилить себе или портировать на Rust

https://github.com/WinampDesktop/winamp