На сайте 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 приложения?

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

Продолжим разбираться с тейками в статье.

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

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

Вот и появился подход view = render(state).
Не стоит его буквально воспринимать, но идея состоит в создании DOM полностью вычисленного от состояния приложения.

Приложения у пользователей бывают неограниченной сложности. Если размещать важную логику и состояние внутри компонентов, то мы приближаемся к концепции — засунуть состояние в DOM.

В одних проектах это работает отлично, вроде простых блогов, админок и лендингах. Я уверен, что даже в чуть более сложных проектах, с доп. инструментами вроде swr/query/... может быть отлично.

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

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

Четвертый тейк попадает в категорию Не корректный. Сравнение не полноценное, хотя бы из-за разницы количества ресурсов необходимых на хранение 1000 нод DOM и 1000 юнитов effector.

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

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

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

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

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.