если будет востребовано, то тут проблем нет)

строить не ломать, пару свойств всегда впилить можно)

тут тоже есть служебные поля
мб и правда туда референс на форму кинуть

так что?

не вариант, ибо сет там - правда сет, который работает, как сеттер)

на change может возникнуть большое желание подписаться, и ждать триггеров на апдейты)

хотя по факту сет - это callonly ивент, так сказать)

о, у меня возникло желание подписаться на set)

считешь пользователей тупыми подсознательно?

store.on(age.set, (state, age) => ...)

<input onChange={event => age.set(event.target.value)} />
?

Нейминг это последнее дело
Это как наклейки в авто, если оно не едет ещё зачем тщательно подбирать шильдики?🌚

откуда такая мысль о:
нет, считаю, что foo.on(field.change, () => …) - семантичее, чем foo.on(field.set, () => …)
set - всей натурой намекает на более "императивное" использование, на то, что его нужно именно вызвать)

ну вот да)
сначала пускай функциональность устаканится, а алиас добавить всегда успеем)

воу воу... ладно

я не отметаю вариант, просто пускай пока в таком виде побудет, если на то будет необходимость, то без проблем накатим другое имя)

меня сейчас интересуют 2 основные проблемы пакетов: это:
- валидация с использованием стейта, вынуждает либо типизировать стейт как unknown (ибо, внутри объекта, невозможно заинферрить его тип), либо делать ее отдельно, формата validation(form, {field: "name", handler(name, state){…}}
- с апи для реакта все не так радужно, как я планировал, и приходится либо делать филд на каждый тип данных, либо на каждое поле определять отдельно, либо делать один филд на все, с проверками в рантайме, но там значения инферрятся как unknown соот-но

по-моему возможно в методе формы заинферрить тип state, так как он выше будет установлен

ты сначала написал, потом типизировать начал? 🌝

про реакт - да, идея давно зародилась, но при реализации, пришлось сильно поменять курс)

в методе формы?

хелп плиз )