TakNePoidet, насколько мне известно вэбпак вставляет динамические импорты как обычный тег script. То есть для поисковика что вставка лично вами что вэбпаком должна быть идентична. Единственное что его может смущать так это повторный два тега скрипт с одним и тем же src. Получается что два запроса за одним и тем же файлом. Не знаю все истории, но мне кажется что ваш тег скрипт лишний.
Григорий Боев, что б\у это понятно. Но б\у чего? Оригинального производителя или китайских мастеров подполья? Там процессоры стоят в несолько раз дешевле относительно доллара. Как такое может быть?
Артур Гранд, если данные новые, то должны быть и новые метаданные totalPage, range, cursor or currentPageIndex. Вы должны строить лдогику приложения так чтобы оно вовсе работало без компонентов. Это называется модель приложения. Визуальные компоненты не просто так называются представлением. Представление в даном случае не от слова view - отображение, а от слова presentation - представление. То есть визуальный компонент лишь представляет или другими словами реперезентует какую-то часть модели приложения.
Поэьтому я просто не понимаю вашу логику, ведь какой-то сервис должен раполагать знаниями о том что он делегирует новый запрос и тот кто генерирует метаданные должен и номер страницы устанавливать. Может это даже сервер. Вообще сервера на себя такую обязанность берут.
Артур Гранд, вот здесь и происходит рассинхронизация в понимании. Вы должны понимать что словосочитание "новый массив" понятно только вам! Я даже гадать не хочу что это означает, так как в моем понимании новый массив в контексте пагенации может быть упомянут лишь в отношении новой порции данных, но тогда не понятно зачем сбрасывать индекс страниц, что требуется при изменении всего поискового запроса, в случаи которого логика должна отталкиватся от фильтра + роутера. Поэтому не исключайте возможность что неправильную логику пагенации вы описали очень понятно, но только самому себе. Это вы в голове держите картины всего кода всего приложения, а у меня кроме ваших слов ничего нет.
Wink007, ререндер означает построение реакт приложения с нуля, а это в сотню раз медленнее обычной статической страницы. Если такое поведение требуется для сведения с ума пользователя, то это стоит реализовать, а если для поисковых роботов, то нет смысла, так как это только усугубит пробюлему по множеству направлений.
Вы хотите реализовать очень странное поведение, поскольку -
1) это нарушает идеалогию реакт роутера
2) это нарушает идеалогию spa
3) Link и так ренеритс в тег
Чего вы хотите добится? Зачем вам невное поведен...
Сергей, я искренне хочу помочь, но вариантов так много, что боюсь вам самому придется в этом разобраться. тем более что я совершенно не знаю на какой результат и как вы тестируете. Кроме того я совершенно не имею возможности выполнить ваш код. Пишите везде console.log и смотрите где результаты отличаются от ожидаемых.
Иван Шумов, нет не забываем! Но забываем об авторе который просит совет в выборе языка для получения опыта построения грамотного сервера. Разве много, денег высокие нагрузки, лучшие умы энтерпрайза, это не залог тех самых знаний о которых спрашивает автор? c#\f# java\scala медленно развивающиеся? Их в основу новых языков закладывают. И заработок на сертификатах как-то невилирует архитектурные подходы и синтаксические конструкции ЯП о которых спрашивает автор?
Ну а php был выбран по причине того что fb писался как pet проект, а потом у них наверное было мало денег и они решили сэкономить на стоимости разработчиков из-за чего им пришлось собственный движок писать.
И давайте ещё раз для автора повторим - язык и его коммунити очень сильно связанны с теми задачи для решения которых они были созданны! Чем круче языки тем круче задачи решаемые с их использованием и тем больше денег на кону. А там где больше денег на кону, там лучшие умы, которые являются евангелистами и пишут книги по архитектурным подходам. Все современные топовые книги по соверменной архитектуре описыввают опыт полученный при создании энтерпрайз приложений написанных на c++/java/c#. О чем ещё можно спорить?
Иван Шумов, тогда подумайте почему энтерпайз языками считают java и c#? Крупные компании вообще не используют nodejs, python на которых к тому же о топовой архитектуре ни слуху ни духу? Вы писали на .net моет на spring? Если да, то чем же nest не клон .net?
Иван Шумов, не согласен с вами вообще. Ваши слова с легкостью можно перефразировать как - jQuery решает большинство проблем бизнеса и помогавет его развитию, поэтому в 2020 году книгу об этой библитеке стоит советовать тем, кто спрашивает совета по изучению клиентской архитектуре.
И как это энтерпрайз не играет роли? Энтерпрайз это крутой бизнес, а какой бизнес такие и архитектурные решения. Кроме того языки программирования всегда создают для решения конкретных задач бизнеса, а реализации множества парадигм способствуют чистоте и разнообразности архитектурных решений создаваемых с их помощью. Поэтому связь языка с отраслью создает для него определенный имедж притягивающий специалистов определенного уровня.
Вся современная топовая архитектура была придумана при создании проектов энтерпрайз уровня. Уровень конторок не предполагает тех свойств, которые решаются с помощью архитектуры. Поэтому не понятно, как это языки и уровень бизнеса не играет роли в выборе отрасли при желании максимального погружения в архитектуру.
Прежде всего нужно разделять абстракции иначе буджет невозможно контролировать сложность. Прежде всего игровое поле. Оно должно быть представлено произвольным графом каждый из которых хранит ссылку на своих соседей (связан 4 или 8 клеток) . Кроме того граф имеет поле data которое ассоциированно с данными о ячейке. Уровнем выше идет игровой мир, то есть его карта. Карта поделена на области и контексты предметной области (города\моря\т.д.) и представляются сервисными классами которые работают непосредственно с графами. То есть вы напрямую с графами не работаете вы через сервесные классы ищите, менеяете значения и т.д. Это уже они внутри себя создают кеши по индексу или ключу или чаще всего и тому и другому.
При генерации игры в самом начале граф позволяет намного быстрее поделить поле на области и контексты или игровые объекты. Затем быстродействие достигается за счет массивов\словарей\списков. Ну а после того как мир построен оочень затратных операций уже практически и нет, так как все сводится к работе с областями представляющих большие участки игрового поля. Поэтому волноватся не стоит.