У тебя на инпуте стоит обработчик на событие onchange. Но сам слушатель состояния useState у тебя стоит в общем компоненте, а ты должен его сунуть в отдельный компонент в котором будет только инпут и кнопка send. И у тебя будет обновляться только этот маленький компонент

Спасибо друг )))

сложна

давно хочу помацать rxjs, но руки не доходят

и пайпы рх строить можно так же и с ивенто и со сторами

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

«делой хорошее, а плохое не делой»

© Да

Вопрос по отписке от setTimeout.

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

запуск функции делающий запрос записан так
const start = setTimeout(get, 200)

вопрос, как отписаться при разминировании компонента?

как это записать в componentWillUnmount, если он ничего не знает про const start?

никак, нужно this.start = ...

все что относится к отображению находится на фронте
Бизнес логика в большей части на бэке, но можно немного на фронте, если сильно усложняется инфраструктура

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

Например, есть какая-то таблица, у нее куча свойств, на фронт нужно просто  данные отфильтрованные отдавать. Вариант 1: фильтровать все на бэке и отдавать конкретные данные, либо вариант 2: отдавать например с сервера все и фильтровать уже на фронте ?

смотря сколько данных

есть простое правило. Если через АПИ напрямую можно сделать что-то, что нарушает логику приложения (конститность данных, разграничение доступа и т д), то это неверно

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

В остальном все зависит от ситуации

Ну ок, нужно посчитать цену со скидкой, фронт или бэк?

Бэк

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

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