Казалось бы, NPM

Но прям кривущий интерфейс

Продолжаю упрощать соединение модели и страницы.

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

Работает так: берем всё что есть в page, фильтруем сущности эффектора и назначаем им соответствия из model.

Я пока не уверен, что лучше: брать page как основу контракта или model. На что это влияет?

Как видим на порядок применения prepend в событиях и map в сторах, а также на имена пропертей. В случае page как основы, назначаются сущности из model в имена из page.

Но если разницы в именах и типах нет, то выглядеть будет так:

contract({ page, model })

Код функции contract выложу позже.
А пока наглядное сравнение исходников.

Если есть предложения или критика пишите в комментариях

Attribute-Based Access Control

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

Почему не готовое решение? Большинство готовых решений монструозны и реализованы на XML.

Нам требуется простая, но в то же время мощная реализация на Kotlin и JavaScript. В идеале, чтобы можно было её визуализировать и собирать вручную.

На данный момент родился такой proof of concept. Если он пройдет battle testing, возможно выпустим в open source.

Типы для метода contract слегка усложнились.

Всё ради большей типобезопасности. В новом варианте появились настоящие гарантии реализации полного API страницы. В прошлой версии можно было передать любой объект без ошибок со стороны typescript.

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

Типы для новой реализации

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

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

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