Дмитрий

Такого метода нет, потому что в языке пока нет дженериков. Где-то в феврале следующего года обещают дженерики завезти с версией go 1.18. А пока что пишем сами.
Го это очень простой язык, но эта простота имеет свою цену.

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

Если комментариев к статье неограниченное количество, то хранить данные таким образом - неудачная идея. В mongodb документ по умолчанию не может превышать более 16 mb, но даже при отсутствии подобного ограничения, это привело бы к единовременному считыванию большого объема данных в память. В таком случае данные следует моделировать также, как и в РСУБД.

Есть CAP-теорема и выбирать тип базы данных нужно исходя из того, какие 2 из 3 свойств для вас важнее. РСУБД дают согласованность и доступность (CA), но жертвуют возможностью разделения такой базы, nosql решения идут другим путем и жертвуют согласованностью в пользу доступности и устойчивости к разделению (AP). Согласованность данных в таких системах достигается при помощи шаблона Saga вместо ACID.

В целом NoSQL это про проекты данные которых не помещаются в рамках одного сервера, а не про то, каким образом моделировать эти данные. Вложенные документы в mongodb - это скорее следствие её архитектуры, которое используют как маркетинговый ход, чем решение, которое будет использоваться повсеместно. В подавляющем большинстве случаев документы будут ссылаться друг на друга, точно также как это происходит и в РСУБД.

Для проекта с крохотными объемами данных логичнее выбирать РСУБД и тем самым значительно упростить себе жизнь. Но в целом как используют NoSQL, шардируют данные и как достигают согласованности данных при отсутствии ACID знать желательно, хотя бы в общих чертах.

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

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

Приемущество Монги в отсутсвии схемы - если схема часто меняется и у вас дохрелион записей в реляционной бд с этим может быть больно, хотя у всех уже давно есть поддержка JSON.
Также вам не нужны никакие join'ы - просто достаёте сразу весь документ. Шардирование делать попроще. Если вам нужно выбирать из нескольких коллекций, то можно это сделать в приложении через отдельные запросы.

Большинство использует её, потому что это просто, быстро разрабатывать, особенно в js - закинул объект да и всё. Не надо про схемы думать. Фигак-фигак. Кто-то использует как объектный кэш.

Я использовал на проекте с документной структурой данных - одна сущность-агрегат, а всё остальное лишь её части и существуют только для неё. И когда часто меняется состав полей. И объемы большие. Одна основная коллекция и несколько коллекций-справочников, которые кэшируются.

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

Доброго дня! Давайте разберемся.

Достаточно ли просто создать div#catalog и рендерить в него компоненты реакта?

Ответ: достаточно просто (ссылка на песочницу). Допустим, имеется шаблон (я использовал HTML, но, думаю, с Blade проблем не возникнет):

<html>
  <head>
    <title>PHP React Test</title>

    <script src="https://unpkg.com/react@17/umd/react.production.min.js" crossorigin></script>
    <script src="https://unpkg.com/react-dom@17/umd/react-dom.production.min.js" crossorigin></script>
    <script src="https://unpkg.com/babel-standalone@6/babel.min.js"></script>
  </head>
  <body>
    <?php
      $INIT_PARAMS = ['user' => 'Vasilij']; // данные из PHP
      echo '<p>Hello React App</p>';
    ?>

    <div id='react-app'></div>

    // React-component. Конечно, лучше вынести в отдельный файл, если кода много.
    //  Еще лучше скомпилировать и подключить минифицированный бандл. Здесь - концептуальный пример.
    <script type="text/babel">
      'use strict';
      const {useState} = React;

      function App({user}) {
        const [liked, setLiked] = useState(false);
        return (
          liked ? (`You (${user}) liked this.`) : (
            <button onClick={() => setLiked(true)}>
              Like
            </button>
          )
        )
      }

      const domContainer = document.querySelector('#react-app');
      ReactDOM.render(<App user={'<?=$INIT_PARAMS['user']?>'}/>, domContainer);
    </script>
  </body>
</html>

И как быть с SEO в таком случае?

Правильный вопрос. То, что мы сделали выше - называется "клиентский рендеринг". Для оптимизации SEO он не очень подходит. Такой способ прост, но используется там, где SEO не нужно (например, приложение, в которое в принципе нельзя зайти, не пройдя процедуру авторизации). Для оптимизации SEO используется серверный рендеринг (SSR), а точнее изоморфная структура приложения (совмещаем SSR и CSR). Но поскольку PHP и JS - разные языки, нам потребуется "компилятор JS" прямо в PHP (мы же хотим скомпилировать JS на сервере и отправить клиенту готовый HTML). Для этого можно использовать V8Js. Почитать подробнее можно, погуглив, например.

Но, наверное, многие согласятся, что такое использование не типично и крайне усложняет и без того сложный процесс. Если Вы хотите попробовать из академического интереса - я кое-что объяснил. Если же мы говорим про best practice, то давайте разберемся, что Вы хотите:

• Использовать PHP?
  
• Или использовать React SSR?
  

1. Если Вы хотите использовать PHP и добавить компонентам реактивности, нечто подобное уже реализовано в Laravel: присмотритесь к laravel-livewire или inertiajs. Я бы рекомендовал laravel-livewire. Инструкция по установке того и другого: jetstream Получите архитектуру, почти как в React, только на сервере. Все живое, стэйт обновляется (как? автоматически через скрытые ajax-запросы). Вот, нашел наспех что-то из своего проекта (public $adJob играет роль состояния):
   

   <?php
   
   namespace App\Http\Livewire;
   
   use Livewire\Component;
   use Illuminate\Support\Facades\Auth;
   
   class AdJob extends Component {
       
       public $adJob;
       
       public function mount($adJobId) {
           $this->adJob = \App\Models\AdJob::find( $adJobId );
       }
       
       public function setReleaserForAdJob($releaserId) {
           $this->adJob['releaser_id'] = $releaserId;
           $this->adJob['status'] = 'in_progress';
           $this->adJob->save();
       }
       
       public function setAdJobDone() {
           $this->adJob['status'] = 'done';
           $this->adJob->save();
       }
   	
       public function render() {
           return view('livewire.ad-job-with-reviews');
       }
   }

   
   И последнее. Если не знакомы с Laravel, но нравится PHP - самое время начать изучать.
   
   
2. Ежели желаете использовать React - то много проще (чем с PHP) использовать React SSR на Node.js. Самые популярные способы:
   
   1. Nextjs, как заметил Андрей Хохлов. Здесь все просто: изучайте документацию по этой технологии.
      
      
   2. React SSR + Express. Здесь, по сути, все то же самое, просто настроить все нужно самому. Хотя, это и более интересно (мне так кажется). Ситуация такова:
      
      1. 
         Создаем React-приложение на клиенте. Делаем бандл. В пункте 3 будет небольшое дополнение сюда.
         
         
      2. 
         На нужных маршрутах на сервере используем
         res.send(ReactDOMServer.renderToString(myElement)) - получаем нечто вроде создания "шаблона" (res.send - API express, остальное - react)
         
         
      3. 
         На клиенте вместо ReactDOM.render() вызываем ReactDOM.hydrate(element, container), это позволяет не создавать разметку заново, а "гитратировать" HTML, отрендеренный React-ом на сервере и полученный браузером.
         
         
      
      Есть также пакеты, позволяющие настроить использование React как шаблонизатора, например: @react-ssr/express. Под капотом он использует тот же renderToString, только с правильной архитектурой и дополнительными, уже настроенными возможностями. В 12-ой строке файла default.tsx из пакета можно увидеть:
      const html = ReactDOMServer.renderToString(app);
      
      
   
   
   

Таким образом, если интерес для Вас представляет именно PHP - рекомендую Laravel + livewire-компоненты. Если хотите именно React SSR - я бы предпочел Node-стэк (Next или Express+React, вначале сам попробовал бы, потом можно попробовать использовать готовый пакет). Вообще best practice - Next.

Есть опыт с Vue в похожей ситуации, суть та же самая.

Где-то в шаблонах формируется контейнер для компонента, в атрибутах которого передаются пропсы для компонента:

<div 
  data-component="ComponentName"
  data-component-props='{ "id": "123", "foo": "bar" }'
>
</div>

Где-то в Component.js происходит инициализация компонента:

// псевдо-код
const el = получили элемент с data-component="ComponentName" или с каким-то id и т.д.
const props = спарсили пропсы из атрибута 
const app = отрендерили React-компонент в этом жлементе передав ему пропсы

С Vue ранее еще пробовали инициализировать приложение прямо на body и использовать кастомные теги для компонентов, но выходило хуже, с пропсами было неудобно.

Из известных крупных сайтов Lamoda например делает что-то подобное. Поищите по исходному коду страницы товара <div class="vue-widget">

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

По опыту использования такого подхода на нескольких средних проектах могу сказать, что подход рабочий. Писать динамические компоненты на Vue гораздо удобнее. Мы написали что-то вроде недо-микро-фреймворка для удобного биндинга vue и не-vue компонентов https://github.com/interfacesdev/nospa Внутри у себя используем, но рекомендовать к вашему продакшену не могу - документация не закончена, поддержки нет, на гитхаб пока просто выдернули актуальную версию с прошлого проекта. Может когда-то руки дойдут заняться плотнее.

А в целом значительно удобнее писать фронт полностью на Vue/React, используя, например, Next/Nuxt для рендеринга и все эти по сути костыли просто от безысходности :( Но это уже тема отдельной дискуссии.

Да, это же обычная связь many-to-many. А option_value это pivot поле https://laravel.com/docs/8.x/eloquent-relationship...

StartupScreen

Оу, май, парень. В этом плане лучше всех CSS-Tricks! И это на самом деле лучший ресурс: трюки, фишки, обучение и гайды с подробным описанием всех новейших технологий в области HTML/CSS (Flex, Grid, красивые менюшки и так далее)

Через IFrame делать слегонца устарело (лет так на 15).
Выводите всё сразу в страницу.
Если что-то не работает ищите причину. Как минимум для более подробного ответа, нужно знать, где Вы выводите php и что внутри самого settings/index.php