Ошибка при неправильной реализации контракта

Исходный код функции на данный момент времени лежит здесь:

https://github.com/accesso-app/frontend/blob/8e8607bd245022586633510468c25cb9c53b9559/src/lib/contract/index.ts

Благодаря effector-reflect мне удалось убрать из кода основного компонента страницы все useStore/useEvent.

Что это дало?
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