Шаблон effector+react+typescript+vike добавлен в документацию Vike!

vike.dev/effector

Буду дописывать разъяснения сразу в Vike. В планах собрать больше рабочих шаблонов для effector.

ПР

Этот пост должен быть тысячным!

На сайте https://effector.dev есть вот такое меню самых важных методов, появляется по hover.

Напишите, что думаете? Насколько удобно? Что можно сделать лучше?

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

Вы можете поддержать меня и мою работу разными способами:

1. Закинуть бусты для красоты и мотивации
2. Раз месяц закинуть немного звездочек или побольше
3. TRON USDT TZ6R5rqcmvBR8VSV9ZsWiS9GmxVkK5oWPV
4. ETH USDT 0x514e40DB37149E5774CEd33FD0EcDD0029B0E769
5. TON UQCRFfgJ6ayaZlxz--eaI3PtfCxBx4_86cRZ5ztOZ25D1Sf2
6. Купить консультацию
7. Записаться на обучение

Всё это не обязательно, но сильно мотивирует и помогает жить дальше.

Хочу поделиться находкой!

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

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

@prog_way_blog

В Node.js 16.9 был добавлен Corepack.
Но уже скоро будет удален!

Основной целью corepack было упрощение использования разных пакетных менеджеров прямо из коробки с Node.js
Теперь же, Node.js принимает меры по удалению Corepack из коробки. Основная причина — стремление упростить дистрибутив и снизить нагрузку на разработчиков.

При этом Corepack уже выделен в отдельный репозиторий, но отделят также и документацию. А пользователям Node.js придется Corepack ставить отдельно.
Но теперь, я не вижу смысла в Corepack, ведь можно просто поставить нужную версию менеджера пакетов, без прослойки в виде corepack.

Статья:
https://socket.dev/blog/node-js-takes-steps-towards-removing-corepack

Дискуссия:
https://github.com/nodejs/node/issues/50963

I tried React Compiler today, and guess what… real life is a bit more complicated.

Автор вспоминает сновные обещания React Compiler:
- "plug-and-play" - просто устанавливать и всё само работает;
- не нужно думать о React.memo, useMemo и useCallback;

Но что, если проверить на практике?

На простых изолированных примерах Компилятор работал как обещано - автоматически мемоизировал компоненты.

Но когда Compiler был запущен на 3 реальных React-приложениях, он смог исправить только 1-2 из 8-10 случаев лишних перерендеров.

Чтобы React Compiler работал корректно, автору пришлось сделать некоторые оптимизации вручную — извлекать компоненты и использовать мемоизацию.

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

https://www.developerway.com/posts/i-tried-react-compiler

Мне кажется, что менять со скругленного на квадратную кнопку-свитч это как минимум странно.

Что это вообще за компонент такой?

Временами возвращаюсь пописать на Swift.

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

Эх, Apple в DX вообще не может…

То есть, если хоть раз платил картой в РФ, то пока аккаунт.

Просто удалят

Хороший ли ты программист?

Bad programmers worry about the code. Good programmers worry about data structures and their relationships.

Изначально цитата Линуса Торвальдса превратилась в тред на StackExchange.

Show me your code and conceal your data structures, and I shall continue to be mystified. Show me your data structures, and I won't usually need your code; it'll be obvious.

Eric S. Raymond.

Интересный поинт. Насколько он актуален в 2024?

https://softwareengineering.stackexchange.com/questions/163185/torvalds-quote-about-good-programmer

Спасибо всем, кто потыкал и написал баг-репорты.
💚

Я

Не так давно, команда в VK поделилась своим неудачным опытом с effector.

Мне было интересно почитать, как минимум это очень важный неудачный кейс. Я как активный пользователь effector не вижу некоторых острых углов, критика помогает. Но чтобы критика была полезной, круто было бы в неё добавить немного конструктива.

Я хочу разобрать некоторые тейки из статьи, с одной стороны они справедливы, а с другой не очень.

Во-первых, статическая инициализация означает, что мы не должны создавать экземпляры сторов динамически. Представьте компонент списка со своим состоянием, которое в случае Effector может быть выражено в виде отдельного стора. А теперь вообразите, что нам хочется переиспользовать логику компонента в нескольких местах, чтобы при этом наполнение (то есть состояние) компонента было разным.

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

Первый тейк, я хочу записать в Справедливые. Всё же, именно эту задачу будут решать модели без динамики в будущей версии effector.

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

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

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

Но этот случай довольно специфичен. Плюс, можно посмотреть на kernel, где операции между юнитами сводятся к чтению свойств объектов и условиям.

А на другой чаше весов, создание инстансов классов при необходимости, что требует выделения памяти, задействования ресурсов процессора. Можно еще немного погуглить о том, что не так с резолвингом прототипов в js. Не говоря уже о производительности Proxy-объектов.

Второй тейк попадает в категорию Сомнительно, но окей. Любой инструмент приносит компромиссы, здесь компромисс это десяток маленьких js-объектов на один юнит.

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

всё состояние нашего приложения целиком висит в памяти, пока пользователь не закроет вкладку 🤔

С одной стороны это конечно так. А с другой стороны, никто не отменял разделение кода на чанки, тогда будет загружено только то, что необходимо.

Но на самом деле все проще, в памяти лежат только начальные значения, ведь мы не начинаем загружать в браузер абсолютно все данные с бекендов при старте frontend приложения?

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