Alex Karo

1) В useEffect добавляем event listener на scroll у window
2) Читаем в обработчике window.scrollY, записываем куда хотим
3) Не забываем удалить листенер при анмаунте компонента (return в useEffect)

Нет, не все сайты работают так (с разделением на фронт/бэк) - некоторые по-старинке. И не всегда новый подход оправдан.
В основном имеет смысл там, где много интерактива - при старом подходе все равно приходится делать апи для всяких lazy-load/поиска/фильтрации, решать где/как будут хранится шаблоны, в каком формате передавать и пр. При новом подходе за все это отвечает фронт, бэк предоставляет только данные.

• Чаще всего используется http+json для взаимодействия фронт-бэк, но есть варианты.
  
• С помощью React мы запрос не делаем. React это что-то вроде продвинутого шаблонизатора. Запрос мы делаем через js (browser api). Бэк только отдает json.
  

Преимущества:

1. Можно разделить работу фронт и бэк команд
   
2. Можно переписать фронт/бэк, используя интерфейс API как контракт взаимодействия
   
3. Между фронтом и бэком бегают чисто данные, без шаблонов. Но см. п. 3 недостатков.
   
4. Перенос нагрузки с бэка на фронт (редко это оправдано, но все же).
   
5. Интерфейс становится более отзывчивым (если делать все хорошо)
   
6. Проще протестировать поотдельности
   

Недостатки:

1. Больше кода, больше компетенций, сложнее система
   
2. Проблемы с индексацией, задейсвуются смешанные варианты (SSR)
   
3. Размер кода на фронте, больше нагрузка на устройства
   

Наверняка не все перечислил - то, что быстро пришло на ум.

Да, можно отправлять запросом, но:
1) Есть функционал очистки кэша по определённым критериям, доступен он только в коммерческой версии nignx
https://nginx.org/ru/docs/http/ngx_http_proxy_modu...
2) Конечно, можно накостылить, чтобы по определённому запросу удалялись файлы. Но лучше это как-то защитить (хоть basic auth). И, кажется, это потребует перезапуска nginx (может и reload хватит).
3) Ещё есть модуль https://github.com/FRiCKLE/ngx_cache_purge - но я не знаю, насколько он сейчас работоспособен

Как вариант - перенести кэш из nginx в другое более управляемое хранилище (например редис) и очищать его при правках.

Современный подход - Intersection Observer API
https://developer.mozilla.org/ru/docs/Web/API/Inte...

Старый - смотреть координаты блока и по скроллу разбирать данные вьюпорта. Пересекли или нет. Наверняка есть какие-то готовые библиотеки для этого.

Мой взгляд, на истину не претендую:

Я сторонник того, что на клиенте вообще не стоит хранить большие объемы данных. Т.е. запрашивает только те, которые нам нужны для работы/отображения в конкретный момент. Все фильтры/сортировка/пагинация на стороне сервера. Понятно, что это не всегда возможно, поэтому идем дальше...

В хранении большого объема данных в редаксе не вижу ничего плохого, если они редко меняются. Если часто - неприятно, нужно поддерживать иммутабельность, затраты на garbage collector.
Плюсы - быстрый доступ до данных, т.к. хранятся они в памяти.
Минусы - поддержка иммутабельности и затраты на память.

Если уж отходить от редакса - можно воспользоваться каким-то стором на основе мутабельных объектов, например mobx.

Если всё это держать в памяти не хочется - то действительно можно взять IndexedDB. Хранится на диске, между перезагрузками сохраняется, асинхронное апи, есть индексы по полям. Нужно учесть, что на браузерах в режиме инкогнито может не работать или работать ограниченно (для предотвращения отслеживания).

Ну и, конечно, вопрос в объеме данных. Просто 2к объектов - не то, чтобы сильно много. Вопрос, насколько тяжелых объектов.

1) Если я ничего не путаю - по умолчанию nextjs не умеет работать с json конфигами. Только с .env файлами. Т.е. используется сторонняя библиотека - какая?
2) А develop.json, в данном случае, не соответствует конфигу для локальной разработки?