Вчера я закинул один из постов в реакт чат и столкнулся с полнейшим непониманием того что из себя представляет signal-component. Поэтому хочется чуток описать свои мысли:

Мысль первая: в случае реакта АБСОЛЮТНО ВСЯ логика должна быть в стейт менеджере. В идеальном приложении должно быть 0 хуков
Мысль вторая: у нас есть 2 хороших стейт менеджера @reatom_ru и @effector_ru, которые форсируют пользователя писать логику глобально.
Мысль третья: условие из мысли 2 мешает внедрять стм в текущее приложение
Мысль четвертая: все кто предоставляет "исправления реакта", такие как преакт, солид и прочие попросту ломают обратную совместимость с реактом и не дают людям писать логику в лучшем стиле.

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

Основные идеи SC донельзя проста:
1) мы вводим 2 фазы выполнения компонента: init и render. init выполняется во время первого рендера и кешируется для последующих ререндеров. render работает как и в реакте
2) мы можем получать внутри компонента пропы исключительно в виде атомов/сторов(далее сигналы). Это позволяет нам сразу писать реактивную логику поверх пропов
3) SC представляет концепцию реактивных компонентов, в пропы которых можно передавать как сигналы, так и примитивные значения. SC сам обернёт значение пропа в сигнал
4) В идеале render слой пропадает и мы попросту возвращаем "реактивный jsx". См. https://news.1rj.ru/str/signal_components/15
5) SC позволяет переписывать только то что вам нужно в данный момент: если вам нужно использовать хуки, то используйте хуки. Это не проблема. Хуки сможете переписать в другое время. См https://news.1rj.ru/str/signal_components/9
6) SC не навязывает то как вам надо писать код. Если вы в итоге захотите вытащить код в глобальную область видимости - вы с лёгкостью сможете это сделать. Если же вы пока не уверены в этом - оставляйте логику внутри компонента.

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

Ну и исходники: https://github.com/XaveScor/signal-components. Я очень серьёзно отношусь к тестам. По идее, из них тоже будет ясна идея продукта.

Поиграться вам на выходные: https://ollama.com/blog/continue-code-assistant

Мои интересы весьма специфичны... #offtop

Мне нравится пленка. А еще мне нравится легкоходство. Но мне не нравятся компакты. Так что я в тупике...

Хочу зеркалку с объективом ~f/2, какие варианты? Pentax me super - 445 г! Стоит от 10к (авито) без объектива.

Посчастливилось найти за 11к, но... с объективом Гелиос-44К-4 который весит 258г - плохо. Лично мне даже в том как центр тяжести распределяется вся эта история не нравится, а уж тем более в разрезе легкоходства. Конечно, дырка 58mm - это великолепно, но хочется альтернативу полегче.

Вообще я сплоховал, надо было сразу с SMC Pentax-M 50mm f/1.7 (165г) что-то найти за 14к, ибо отдельно он стоит около 8к.

Начал искать мелкие альтернативы. При этом, хотелось бы сохранить большую дырку. И спустя два часа я случайно натыкаюсь на МС Зенитар-К2 2/50 - просто пушка-бомба, судя по отзывам. Стоит всего 3-4к.., я так сначала нагуглил. Начал искать где и какой взять и провалившись еще немного в кроличью нору открываю для себя фотоаппарат для которого объектив и был создан - Зенит-КМ, супер бюджетная и легкая зеркалка.

Фич у него достаточно много, но интереснее вот какой момент. За 3-4к на авито мы можем взять комплект из:
- Зенит-КМ плюс - 480г
- МС Зенитар-К2 2/50 - 189г
- добавляем 4 пальчиковых батарейки - выходит до 750г

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

P.S. ну вот интересно мне находить бюджетные профитные варианты, борюсь сам с собой за каждую копейку в этих вопросах, это как спорт для меня.

UPD:
- пентакс приехал, оказался сильно убитым, отправил обратно и заказал другой: Pentax ME (без Super) + тот самый SMC Pentax-M 50mm f/1.7, жду
- тем временем, приехал зенит, в целом оч прикольно, хотя автоматическая перемотка только мешает, получается и батарейки зазря таскаю. Зато у зенитара минимальный фокус до 35см - оч круто!

Меня спрашивает начальник как оно.

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

Тем временем сетап:

Что такое бизнес логика (БЛ) и как ее писать

БЛ - это базворд, забейте вообще и прекратите использовать этот термин :) Причин несколько, но главная - бизнес сам не умеет ее описывать и даже формулировать.

Логика и ее автоматизация может быть реализована программой ЭВМ. Программирования - это алгоритмы и структуры данных. Структуры данных - это данные с ограниченным набором алгоритмов. Алгоритм - это система / совокупность последовательных операций, т.е. формализованная логика. Поняли что все это одно и тоже в разных представлениях?

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

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

Какие в программировании есть способы борьбы с вариативностью? Известно давно(!) - конечные автоматы (КА). Надеюсь, вы все с ними знакомы и умеете применять. И, конечно, используете TypeScript и описываете именованные варианты (юнионы) ваших состояний.

Конец.


Проблем у КА две: всегда огромный бойлерплейт или вообще бесконечный бойлерплейт от комбинаторного взрыва некоторых алгоритмов.

Что же делать? Давайте пойдем от обратного и посмотрим какими свойствами обладает код на КА и как мы можем их достичь иначе.

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

Какие у нас есть способы описать вариативный код, можем ли мы от чего-то избавиться? Способы:

- условные операторы
- GOTO колбеки
- виртуальные связи (реактивность)

От условных операторов нас учит избавляться ФП и мы не будем сейчас разбирать почему это плохо. Оставим их.

Что на счет вынесения части кода в колбеки и реактивность? Для последовательных процессов - это явный антипаттерн, который нужно применять в самых редких случаях. Есть ли у нас инструменты избавления от них? Да, очень просто, обычный await.

Если вы недавно начали писать на JS и не застали повсеместную миграцию с промисов на async/await - рекомендую найти такие задачки и поупражнятся, поможет понять как хорошо мы сейчас живем.

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

Все, вы прекрасны :)

Одно важное уточнение и подтверждение своим словам хотел бы добавить. Есть у нас индустрия, важная цель которой написание той самой "бизнес логики" в виде менеджерочеловеко-понятного не программисту кода. Это интеграционное тестирование! Код на каком-нибудь сайпрессе или CodeceptJS максимально возможно приближен к естественному языку. Разбирал это подробнее в этом стриме. Что вам мешает так же писать реализацию логики?

https://phryneas.de/react-server-components-controversy

Почитайте сами, много интересного.

Пара-пара-пам, фьиу.
https://sansec.io/research/polyfill-supply-chain-attack

В последний раз в @artalogg вспоминали историю реакта (запись сохранилась в канале). А вот часть ключевых материалов по которым мы прошлись:

- Alex Kotliarskyi: Facebook product Infrastructure - рекомендую к просмотру доклад (на русском) про культуру разработки в ФБ и историю React.
- useCallback() invalidates too often in practice и неудавшийся useEvent про фундаментальные проблемы ререндеров и хуков.
- React Context value propagation performance - а вы помните как react-redux несколько мажоров подряд менял бекенд подписки?
- Support asynchronous server rendering (waiting for data before rendering) висит с 2014г.
- [Concurrent] Safely disposing uncommitted objects - про проблемы очистки мусора.
- useState not bailing out when state does not change - про, в некоторых ситуациях, бажный батчинг.
- What is the reason to patch the fetch? - про патчинг глобалов (там есть еще ссылки на подобные случаи).

Еще обсуждали пачку багов, обсуждали https://prepack.io/, обсуждали как можно было бы сделать нормально. Ну и закончили рекомендацией (пере)читать все статьи https://dev.to/thekashey

Вы согласны что такая инкапсуляция зависимостей делает код максимально понятным и предсказуемым?

https://github.com/dmtrKovalenko/subnoscriptr

Дима Коваленко зарелизил веб морду (localfirst) для fframes. Проект на ризоне, может быть кому-то будет интересно поизучать, ну или использовать :)

Вот тред от него по ключевым UX решениям: https://x.com/neogoose_btw/status/1812242086910931410

Дейли ремайндер, вас ждут 200$. Я уже даже спросил автора Putout как это сделать, и он все расписал: https://github.com/artalar/reatom/issues/523#issuecomment-2192042677