Уверен что на эту фичу будет тренд в скором (тут не уверен) времени. Вопрос только кто сделает ее массово пригодной первым: реатом или другой фреймворк / либа?

Инвайт в Arc.

Работает только на MacOS, количество активаций ограничено!

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

До этого пробовал: Sidekick, Vivaldi, Opera, Brave, Firefox, Chrome, Yandex, Edge.

Бтв, meetsidekick.com понравился, советую, но Арк заметно лучше.

UPD: в комментариях делимся инвайтами.

В комментариях все тоже делятся инвайтами, вы крутые! 🤗

Совсем забыл, сегодня же пятница!

Методология как конструктор: инструкция по сборке / Филипп Дельгядо

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

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

https://www.youtube.com/watch?v=Jt2C4ta1rEo

#managment #process #recommended

В 10-30 (gmt-0 !) постримлю разработку адвансед кеш-политик для https://www.reatom.dev/packages/async

пару мин

На выходных зарелизил третию версию Act - самой быстрой + маленькой + корректной библиотеки для реактивных стейтов. Напомню, ее можно использовать в React и Svelte без биндингов!

Это становится интересно, кажется, она достаточно стабильна.
Возможно, она будет референсом для минимальной имплементации реактивных стейтов и в других ЯП, всего сотня строк в исходниках позволяют. Я их еще подрефакторил и немного комментариев накинул. А @dzakh_dev начал делать порт на ReScript! Уже стоит создавать организацию с репами под разные ЯП?)

Кому интересно, алгоритм:

Подписчик - источник истины. Подписываемся на компьютед акт, он собирает все свои используемые зависимости и их состояния (зеленые стрелки).

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

Каждый мутируемый акт при его чтении сохраняет текущего подписчика - от которого чтение и идет (красные стрелки).

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

Когда мутируемый акт меняет стейт, он очищает список подписчиков и вызывает их.

У компьютедов нет ссылок на тех кто от них зависит и это главное отличие от классического дерти чекинга.

Как вы, возможно, заметили, все списки иммутабельные.

Каждая нотификация об апдейте мутируемого акта имеет версию, которая помогает кэшировать посещенные компьютеды.

Основным ограничением является оверхед на чтение компьютеда вне ракции. Поскольку мы можем иметь кэш посещений только во время нотификации, любой апдейт в одном графе делает невалидным кэш другого графа. Но это редкий случай в полностью реактивной системе, и сама инвалидация обходится дешево. Еще может быть редкая(!) проблема с не отпиской от не используемого ActValue (я это исправлю попозже), подробнее в самом конце доков.

Задавайте вопросы, если что-то не понятно, постараюсь поправить описание.

AMA

Вот вам ещё поинт: описывая catch вы должны учитывать все возможные нижележащие ошибки. Ролбек же описывает только логику отката того кода где он описан.

Койкто (не я) делает новый фронтенд фреймворк и придумывает апишку для статических темплейтов, как вам такое? Поставьте смайличек плз.