Меняется роутинг и форма (регистрация, авторизация)

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

Информацию о том, какой таб открыт в данный момент норм хранить в локальном стейте компонента, но ровно до того момента, когда эта информация понадобится за пределами этого компонента

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

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

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

открытый таб должен храниться вне компонента, ибо это не временное состояние

ты странными категориями мыслишь. у тебя есть табы, у них не должно быть onClick. Должен быть onSwitch(tab: string), например.

ты странными категориями мыслишь. у тебя есть табы, у них не должно быть onClick. Должен быть onSwitch(tab: string), например.

или onChange(event)

SyntheticEvent? не

можно onChange(tab: string, event: SyntheticMouseEvent)

нет, лучше уж первым ивент, ближе к стандарту

SyntheticEvent? не

я типы не указываю прост)

не согласен

ты выносишь кишки компонента наружу

id открытого таба это не кишки

Ну я мыслил так. Есть таб, который является спаном. Я на него кликаю, следовательно событие onClick

сегодня switch по onClick, завтра по keyPress

я про event

Ну я мыслил так. Есть таб, который является спаном. Я на него кликаю, следовательно событие onClick

ну немного не то в плане компонента ты делаешь change или switch

Ну я мыслил так. Есть таб, который является спаном. Я на него кликаю, следовательно событие onClick

не. есть таб. у него есть верстка - и насрать какая. А есть его внешний api - вот тут очень важно отделить его от верстки

Мне кажется или вы про одно и то же?

Просто про разные названия

не, это важно. onClick - это кишками наружу. onChange/onSwitch/onTabUpdate - это ок

не. есть таб. у него есть верстка - и насрать какая. А есть его внешний api - вот тут очень важно отделить его от верстки

согласен. В плане поддержки потом скажешь себе спасибо

какой PropTypes задать для мапы строка-число вида {'10': 14,'15': 313, '514': 2231,...}? кол-во ключей динамическое

PropTypes.object eslint не пропускает

какой PropTypes задать для мапы строка-число вида {'10': 14,'15': 313, '514': 2231,...}? кол-во ключей динамическое

PropTypes.objectOf(PropTypes.number)

спасибо

ктонибудь в курсе может, в БД хранится текст с \r\n т.е. с переносами строки. когда получаю в стейт и вывожу из стейта, они теряются. хотя бд отдает json с ними

react по-моему удаляет все такое

нашел. надо задать css - white-space: pre-wrap;

ктонибудь в курсе может, в БД хранится текст с \r\n т.е. с переносами строки. когда получаю в стейт и вывожу из стейта, они теряются. хотя бд отдает json с ними

ну как бы html символ переноса это <br/>

Пытались делать серверный рендеринг на java c большими объемами данных. Решение работало 2 месяца и на него решили забить, отпало желание все это подерживать.

проект не от ВТБ отпочковался случайно? )))

проект не от ВТБ отпочковался случайно? )))

Нет мы ещё хуже...

Нет мы ещё хуже...

а то очень уж любят банковские работники на бэкенде из Java писать сайты )

а то очень уж любят банковские работники на бэкенде из Java писать сайты )

чотакого?

playframework и все

ну или еще попроще чего уже есть

чотакого?

ничего плохого, но обычно после ухода ключевого разработчика поддерживать ЭТО становится некому

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

playframework и все

Заказчик хочет сайт на liferay

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

Есть ещё гос. сектор

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

да почему?

программисты дорогие или писать долго?

Из вышесказанного можно резюмировать, что всю мелкую работу с ui лучше делать в самих компонентах с использованием синтетик ивэнт

Так?

Из вышесказанного можно резюмировать, что всю мелкую работу с ui лучше делать в самих компонентах с использованием синтетик ивэнт

ну вообще да но разговор же был о state

Ну я все равно не понял что делать с 13 li

Вешать on change на все?

откуда в <li> onChange

Ну вот у меня 13 селектов, которые ещё и сделаны как li, к каждому привязана маска инпута. Мне получается на все селекты онклик повешать?

мм, onChange + value

Я вот и спрашиваю

если это <li> то onChange там нет. на селектах есть onSelect

s/onSelect/onChange

Ну получается надо 13 онкликов вешать?

если у тебя кастомные селекты на <li> элементах - да

события умеют всплывать так-то но не помню, как с этим в реакте)))

нормально с этим в реакте. но он сам делегирует

Ну там вообще нет селектов ul с li просто принцип работы как у селектов

вешай onClick. реакт однохренственно на root компоненте слушает все события от дерева и сортирует. нет нужды возиться и заниматься ненужной микрооптимизацией с делегированием

У меня ещё такой вопросик есть, как маски телефонов делаются, в гугле только джквери библиотека

Хочу в общем без библиотек сделать

есть react-masked-input или как-то так

https://github.com/insin/react-maskedinput

кто как делает сабмит формы для редактирования данных, когда обновление денормализованного объекта может состоять из 3-4 запросов на разные эндпоинты

а чего это на бэк не перенести? или к бэку доступа нет7

ERROR: S client not available

?

нету доступа

а в чем именно грабля? четыре запроса, конечно, не самая приятная ситуация но не так чтобы невозможная

да грабли нет, я понимаю что можно вообще убрать сабмит и сделать каждое поле обновляемым по onchange или делать диффы на сабмит и разбивать потом данные по разным запросам, мне интересно какими способами вы решали это, может что интересное будет

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

согласен на 100%

это если монолитный бэк то да, а если куча микросервисов то приходится фронту всем рулить

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

у меня такая же ситуация

там как раз изза many-to-many обновление одной сущности разбито на кучу эндпоинтов, но редактироватся оно должно в одной форме как денормализованный объект

это через очереди и воркеры должно делаться на беке

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

у меня такая же ситуация

мрачновато. фронт от бэка отделен здоровенной такой хренью как сеть - ни транзакций ни гарантий доставки

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

имхо

это если нужна транзакционность, согласен

к сожелению пока бэк не поменять, поэтому я сделал каждое поле, как отдельная форма, на onchange с троттлингом посылается update, на одни и теже либо разные эндпоинты в зависимости от поля

в моем случае это только на update, и там можно одну часть отправить а другую нет

коллеги, у меня другой вопрос, тут ведь многие редаксы используют? сталкивались ли с древовидными структурами типа inerface Node { id: number, children: Node[] } Как решали задачу иммутабельно добавить/удалить ноду в дерево?

можно конечно развернуть в плоский список, тогда все понятно

есть алгоритмы иммутабельного обновления дерева

что значит иммутабельно в контексте дерева? дерево должно быть представлено каким-то внутренним объектом тогда есть смысл говорить об иммутабельности

как и в контексте любого другого объекта, ты не можешь сделать tree.children.push()

так в этом и вопрос был

или вы не мне это поясняете?

иммутабельное обновление - это по сути копирование с заменой/удалением/добавлением части при копировании

это для @aleksxor было

а, ок

вопрос был про то как дерево представлено. я так понял что реализация наивная - каждый элемент с корня это { id, children: [<ids>] }.

я бы порекомендовал глянуть в immutable.js. не пробовал там сильно глубокие рекурсивные структуры разбирать. но неглубокие вполне

нет, не children: [<ids>], я структуру выше привел в виде интерфейса TS

в общем, погуглю тогда алгоритмы, спасибо