Ты про строгую или про статическую типизацию?  Я думал, что все лиспы строгие

+

Да и на него можно повесить вотчер:))))

мне кажется derived-атомы (типа reactions из реагента и типа курсоров) это решение проблемы "всё в одном атоме неудобно, сложно отследить когда что перерендеривается и т.д.". с другой стороны мне кажется у атомов замкнутых в компонентах должно быть очень ограниченное применение: только для временного локального состояния, которое не важно для бизнес-логики (вроде того на какой месяц мы смотрим в компоненте выбора даты. а выбраная дата это уже часть состояния бизнес-логики)

и даже последнее лучше в глобальную базу положить

последнее в смысле какой месяц виден?

ага

у браузера есть компоненты типа календаря или селекта. пока ты выбор не сделал ты не видишь никакого стейта. мне кажется к своим компонентам стоит подходить так же, потому что иначе есть риск сильно усложнить пространство состояний приложения for no good reason.

tests are good reason

а что с тестами?

в рефрейме можно оч хорошие тесты писать на модельную часть

и рано или поздно месяц в календаре станет частью бизнес логики

надеюсь мы выложим наши наработки  в этой области  - станет яснее о чем я

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

грубо говоря я хочу иметь возможность вместо своего календаря легко взять или браузерный <input type=date/> или какой-нибудь готовый реакт-компонент из npm и всё должно продолжать работать

это ООП - размазать мутабельный стейк по приложухе

и страдать :)

прикрываясь инкапсудюляцией

это абстракция. если у меня есть календарь, то я хочу компонент, который [calendar {:selected-date @my-managed-state }] и вот @my-managed-state это мой мутабельный стейт, а что творится внутри calendar не важно. если становится важно, то добавляем параметры и менеджим новый стейт тоже глобально