Какой логики придерживаться при реализации данных компонентов?

Question

[Владислав Андреев]

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

1) Данные в таблицу приходят по скроллу вниз, то есть в родительском компоненте должно быть что-то, связанное с IntersectionObserver API?

2) Должны ли данные в таблице подгружаться после клика по кнопке найти или как только я выбрал какой то из фильтров в селекте?

3) Допустим, я выбрал какой то фильтр, сначала данные отфильтровались, но затем я начал листать вниз, выходит, приходят уже новые данные, которые перетирают текущее состояние таблицы. Я думаю, что при получении именно, что отфильтрованных данных нужно перестать стягивать с сервера новые данные, а затем после сброса фильтров снова позволить компоненту фетчить новые данные, я правильно понимаю?

Comments

[deantek]

1) infinity scroll погугли
2) как угодно, зависит от того как нужно бизнесу
3) обычно это какой-то запрос с гет параметрами, тебе сразу придет массив с отфильтрованными данными, ничто перезатираться не будет

Как пример

site.co?search=anna&developer=fullstack

Обычно вот так выглядит запрос, тебе вернутся все фулстек Анны, надеюсь понятно объяснил

[Владислав Андреев]

deantek, только что глянул Swagger предоставленного мне апи, увидел, что поддерживает параметры в запросах. Это тестовое в компанию, поэтому догадаться, как работают фильтры предстоит конкретно мне) Спасибо за ответ.

[Владислав Андреев]

deantek, а еще вопрос, вот мне придет новый массив с новыми данными, если я вниз буду листать, листая этот отфильтрованный массив, то по идее новые данные фетчить я не должен уже? А то там по тз скролл бесконечный ведь.

[Константин Б.]

Владислав Андреев, верно) это называется race condition. Решается либо через отмену запросов, либо через промис обёртку в временной меткой.

[Владислав Андреев]

Константин Б., благодарю!