Sergiu Mitu

Спрятать не выйдет, а вот затруднить немного чтение вполне. Например с помощью обфускации. Но будьте готовы к увеличению объёма кода.
Например console.log('Лол, кек, чебурек'); превратиться в

var _0xac52=["\u041B\u043E\u043B\x2C\x20\u043A\u0435\u043A\x2C\x20\u0447\u0435\u0431\u0443\u0440\u0435\u043A","\x6C\x6F\x67"];console[_0xac52[1]](_0xac52[0])

. Оно вам надо? ИМХО всё это детский сад.

Защитить JS нельзя, т.к. он выполняется на клиенте, а не на сервере.
Можно усложнить чтение с помощью обфускации. Это отсеет 90% любителей, но особо упорных это не остановит и они прочтут твой код. Тем более, что есть инструменты, помогающие в деобфускации: деобфускаторы, бьютифайеры и пр.
Хочешь скрыть код - уходи из фронтенда и добро пожаловать в бэкенд, на сервер.

Хочется услышать отрицательные стороны вебсокета

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

РЕШЕНО
нашелся экстеншен, который собирает все ресурсы в zip, включая эти виртуальные файлы вебпака

https://chrome.google.com/webstore/detail/save-all...

Реакт — это не фреймворк для SPA, а библиотека для создания интерфейсов. В крупных и/или старых веб-приложениях, особенно на этапе постепенного внедрения нового стека и перехода на SPA, вполне уместна и практикуется описанная вами схема, когда роутинг реализуется классически через многостраничность, а рендеринг происходит частично на сервере, а частично — на клиенте, причем дорисовываемые на клиенте куски интерфейса ("виджеты") могут быть как компонентами, так и самостоятельными реакт-приложениями (вместо реакта можно подставить любую другую библиотеку/фреймворк). Передавать данные через window тоже нормально, если эти данные уже были сформированы на сервере и использованы для серверного рендеринга.

Используют очень много людей. Дело вкуса. Удобно делать темизацию, в ущерб читабельности и производительности.

https://developer.wordpress.org/rest-api/

WordPress — система управления контентом. То есть, ключевая функция — это работа с БД, это предоставление интерфейса (читай админки) через который вы можете просто управлять контентом на сайте.

SPA — архитектура для построения интерфейса. То есть это алгоритм по которому ваш контент как-то отображается.

Совместить их достаточно просто. В общем и целом у вас должно быть две отдельные программы (на одном сервере, или на разных не столь важно)

1. WordPress который будет управлять всем что связано с контентом. Создавать новые записи, рубрики, связывать их и тд.
   
2. SPA, который просто будет принимать инфу от WordPress и как-то её отображать.
   

Оба приложения могут работать абсолютно независимо. Вы можете сделать два разных SPA (например для десктопа и для мобильных) которые будут работать с одной и той же базон полученной от WP. И даже разработкой этих независимых систем могут заниматься разные люди.

Вот статья на эту тему
https://medium.com/@moustachedesign/creating-a-web...

Не используй React Native, полученный результат не оправдает вложенных сил и времени.

https://zalog.ro/placeholder-loading/
https://github.com/danilowoz/react-content-loader/

Это называется skeleton screen loading.

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

Если фрагмент строго попиксельно идентичен куску большого изображения, то всё просто.
Берется первый ряд пикселей фрагмента и проверяется его вхождение в ряды пикселей исходника.
То есть это фактически задача поиска подстроки в большой строке. Это суперклассическая задача, по ней написаны тонны научных работ, разработано стопиццот оптимизированных алгоритмов, многие реализованы в библиотеках. Да хоть википедию можно смотреть:
https://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D0%B8%D...
Если найден - проверяются последующие ряды.

Вот если вхождение нестрогое (например, фрагмент отмасштабирован, или яркость не совпадает, или просто немного покоцан jpeg-пересжатием) - тогда всё сильно сложнее.

По коду кажется все ОК (никаких сильных претензий не возникает сходу), только по-моему пагинацию прикрутить вы забыли (она нигде не вызывается).

UPD: претензии небольшие все таки есть, class Results:

renderNoResultsMessage() {
    const { results, noResultsMessage } = this.props;
    if (results && !results.length && noResultsMessage) {
      return (<div className="no-result">
        <h3>
          {noResultsMessage}
        </h3>
      </div>);
    }
  }

Кажется эта функция не очень то renderNoResults, она еще checkForResults, а только потом render - не надо так делать, по коду непонятно. функция, которая renderSMTH -должна только рендерить, без лишних проверок

UPD 2 пагинацию увидел, с ней все ок.