Что это дало?
1. Теперь при изменении любого инпута ререндерится только компонент этого инпута, а не вся страница
2. Я могу назвать каждый компонент индивидуально исходя из его назначения:
<Email placeholder />
вместо:
<Input type=“email” value={email} onChange={emailChanged} placeholder />
3. Экономится место в общей структуре страницы. Большую сложную страницу теперь гораздо проще осмотреть целиком, глаз не цепляется за “служебные” пропсы, здесь только визуальные.

“В погоне за декларативностью” мы изобрели компонент Branch, он принимает два child и if:
<Branch if={true}>
<First />
<Second />
</Branch>
Первый child рендерится если условие в if истинно, второй если ложно, но его можно не передавать.

reflect позволяет прибиндить условие к Branch сразу же, дав ему имя:
const BranchIfEmailValid = reflect({
view: Branch,
bind: {
if: every({
stores: [$isEmailValid, $error.map((err) => err === null)],
predicate: true,
}),
},
});

После того, как я описал механику работы Branch, понятна ли структура страницы и смысл всех элементов (не учитывая время на привыкание)?

Немного боли благодаря фронтенду

talkstream #3 был посвящен архитектуре React-приложений.

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

Сейчас реализовал наивную версию match для effector/reflect.

Метод выбирает компонент из cases соответствующий значению в сторе source, во время рендера привязывает сторы и ивенты к нему.

Оказалось, что похожим образом можно реализовать декларативную замену useList в виде list. Это всё похоже на движение от хуков к декларативности, при этом упрощая использование связки реакт-эффектор.

В формах, которые мы сейчас пишем в Redmadrobot и готовимся анонсировать есть план по поддержке декларативного описания сложных динамических форм.

Заметил, что часто новичкам в Effector хочется понять способ мышления при построении логики.

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

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

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

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

https://anchor.fm/under-a-dome

Как вам такой формат?

По следам обсуждения в Чате для совят записал спич про http статусы в бизнес-логике.

https://anchor.fm/under-a-dome/episodes/HTTP---graphQL--protobuf-eqaqub

Ну что. Давайте потестируем ваш ClubHouse

Создаю организацию в Github, а там капча нового типа.

Прямо в сердце!

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

Вот глядите: https://bundlers.tooling.report/

Ночью не мог уснуть из-за очистки дорог от снега и записал выпуск подкаста «Под куполом» о человеческом сознании.

https://anchor.fm/under-a-dome/episodes/ep-eqgr9l

Подкаст появился на Apple Podcasts и Google Podcasts.

Яндекс.Музыка таки опубликовала тоже
https://music.yandex.ru/album/13932760

Хочу напомнить, что со мной всегда можно созвониться и получить консультацию по моим профильным темам: фронтенд, архитектура, React, Effector и миграция на новые технологии.
На данный момент мне удобнее всего получать оплату через ВК, но есть и другие варианты, о которых можем поговорить в ЛС.

Ссылка на ВК
Ссылка на BuyMeACoffee

Я ужа достаточно давно исследую архитектуру современного фронтенда, мне интересно с каким эмодзи у вас ассоциируется идея и подход feature-slices?

Голосование в чате

Крутая статья погружающая в Rust.

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

https://fasterthanli.me/articles/a-half-hour-to-learn-rust

Давненько не писал сюда, а сейчас появился существенный повод.

Я уже давно рассказываю об архитектуре frontend-приложений и стараюсь явно показывать свои ошибки и опыт.
Весь этот опыт вылился в подход FeatureSlices, который на данный момент уже претерпел два серьезных изменения. Подход преследует простые цели — стандартизация структуры frontend-приложений. Конечно же, я не один работал над подобным подходом, как и ребята из команды feature-driven. Не так давно мы начали объединять усилия и опыт в одну общую команду и единый подход.

7 марта в 13:00 МСК прошёл первый публичный созвон-стрим, на котором мы постарались обсудить три основные темы:

1. Выбрать финальное название(главный кандидат сейчас — feature-sliced) и подобрать домен
2. Выяснить, что есть feature и entity в рамках методологии
3. Определить roadmap по ближайшим действиям

https://youtu.be/RQBslp8dngA

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

https://github.com/feature-sliced/wiki/discussions/43

Уже несколько недель думаю как назвать библиотеку для проверки прав в стиле ABAC.

Все самые интересные названия заняты, вот какое-то мучение. Сейчас пришла в голову идея: npmjs.com/can-you

Достаточно хорошо описывает цель: проверка прав?

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

Если я вижу функцию employeeStatusChange, я хочу четко понимать её назначение “сменить статус сотрудника” или же “узнать в каком состоянии находится процесс изменения сотрудника”.

Если коротко, то использую подход:
Namespace + HighContext + LowContext + Action

Примеры выше можно показать так (namespace отсутствует):
employeeStatusChange
employee — high context, в контексте чего выполняется действие
status — low context, нечто принадлежащее родительскому контексту
change — action, что делаем с этим
То есть изменяем статус сотрудника.

А вот пример с выяснением текущего статуса процесса изменения сотрудника, может выглядеть так employeeChangeStatus:
employee — high context, всё так же работаем с сотрудником
change — low context, но здесь уже указываем что работаем с сущностью change принадлежащей сотруднику
status — action, выступает как глагол

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

А вот как быть БЕЗ конвенции? Как отличить эти функции не превращая имя в месиво вроде readStatusOfEmployeeChanging, которое не отсортировать по имени, потому что тогда сгруппируются все функции начинающиеся с read*, вместо группирования по сущности employee.

P.S.
Если переложить этот подход на точечную нотацию, получится вполне себе вменяемая объектная модель:
employeeChangeStatus -> employee.change.status()

А вот readStatusOfEmployeeChanging уже не перекладывается без полной смены порядка слов, что не очень приятно. Ну и важные слова employee и change теряются в середине и конце названия.