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

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

https://react-hook-form.com/

Ты хочешь сказать что тут вся форма не апдейтится по тайпу в поле?

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

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

ух вот это оптимизации

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

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

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

ты юзаешь стейт в форме внутри инпуты и ты думаешь обновив стейт не должно быть апдейта ? Там апдейт. В дом может ничего не попало

React.memo, PureComponents, нет?

https://final-form.org/docs/react-final-form/examples/subscriptions

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

https://final-form.org/docs/react-final-form/examples/subscriptions

Можно ли что то придумать новое в плане ToDo? В том плане что ничего придумать невозможно и остаться скопировать и вставлять то что придумали другие

Можно ли что то придумать новое в плане ToDo? В том плане что ничего придумать невозможно и остаться скопировать и вставлять то что придумали другие

Можно ли что то придумать новое в плане ToDo? В том плане что ничего придумать невозможно и остаться скопировать и вставлять то что придумали другие

Структура

не помню спрашивал или нет, но чем отличается widgets от blocks

Твой код всеравно будет отличаться

не помню спрашивал или нет, но чем отличается widgets от blocks

Можно ли что то придумать новое в плане ToDo? В том плане что ничего придумать невозможно и остаться скопировать и вставлять то что придумали другие

Продолжаю рассказывать про новый опыт разработки с использованием минималистичных (в плане бандлсайза) решений. Проекту всего месяц, пока там 3к строк кода только написано (с учетом кверей и стилей). Стоит заметить что сам по себе next тянет лишних 50КБ, от которых тоже в планах избавиться, когда релизнется новый preact-cli. В итоге я делаю вывод что можно забандлить форму авторизации в 200КБ и в ней будет вообще все: template executor (preact), СТМ (reatom), ui-kit (reakit + reshadow), слой работы с сетью (graphql-request) и все это с максимальным DX.

🤔и намешанный везде case

а какой плюс у graphql-request??

не помню спрашивал или нет, но чем отличается widgets от blocks

Типы полностью автоматически билдяться и выводяться для кверей, я их не пишу вот прям совсем :)

И то и то не имеет семантики

Блоки - это тупые атомарные компоненты ui-kit’а. Виджеты - это стейтфулл фичи со своей БЛ

вот что типы нагенерит тебе https://graphql-code-generator.com/

почему не атомик дизайн?

Сирисли?)))

А я-то думал))

А если бы обычным способом писал сколько бы весило?

Переусложнен, не вижу смысла так сильно все делить.

а как ты пишешь на нексте и на преакте одновременно? разве это не противоречащиеся штуки?

Можно ли что то придумать новое в плане ToDo? В том плане что ничего придумать невозможно и остаться скопировать и вставлять то что придумали другие

Вопрос - норма ли делать features/feature/lib, нормально ли делать features/common/ и, следовательно, нормально ли делать features/common/lib ?

Преакт полностью совместим с реактом https://github.com/aomkirby123/nextjs-preactX

Ага. Если только в проекте есть несколько внушительных статей объясняющих семантику

А я-то думал))

🤔а вот widgets blocks как-то привыкать долго, и как часто будут вопросы у разрабов "куда положить?"

blocks - это самый старый нейминг, который использовали еще до jquery, наверное. С виджетами тоже самое.

ты прочекай, мы пока не юзаем, но там очевидны плюсы, а еще аполо нету в зависимостяъ, у тебя другой клиент?

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

Вопрос - норма ли делать features/feature/lib, нормально ли делать features/common/ и, следовательно, нормально ли делать features/common/lib ?

🤔а вот widgets blocks как-то привыкать долго, и как часто будут вопросы у разрабов "куда положить?"

lib – да features/common — если можешь придумать как избежать, лучше избежать common/lib думаю можно вынести в src/lib

ну...

блокс - это ui-kit. Они не знают про доменную область приложения. Виджеты знаю, они подключают данные и отдают их набору блоков

что переусложнено, не понимаю, я просто пользуюсь таким образом что атомы- тупые компоненты, молекулы совокупность атомов и организмы - совокупность атомов и молекул + бизнес логика

а что у вас кешами рулит? и прочими плюхами?

Моя самая большая претензия к одному общему списку компонентов, это то, что их охренеть как много будет. И разрулить это просто невозможно

стейт-менеджер

Казалось бы, назови blocks просто ui и уже станет в разы проще. А widgets назвать components )))

Моя самая большая претензия к одному общему списку компонентов, это то, что их охренеть как много будет. И разрулить это просто невозможно

Структура

Моя самая большая претензия к одному общему списку компонентов, это то, что их охренеть как много будет. И разрулить это просто невозможно

Огромные ui-kits как-то живут с плоской структурой же

стейт-менеджер

так он же не закешит так как аполо или надстройки еще написаны?

Вот добавь сюда пачку бизнес логики. И сразу станет вопрос куда положить переиспользуемый код

libs / services