the5x

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

Ты, во-первых, не понимаешь что такое dependency injection, а во-вторых - что делает твой код.

Если отбросить все умные и красивые слова которые ты тут наскреб по сусекам, то оба твоих примера - про type hinting. Только в первом кусочеке кода мы просим интерпретатор проверять входящий параметр, а во втором - возвращаемое значение.
Type hinting двольно размытый термин, мне больше нравится "контроль типов", который используется в документации. Поскльку в данном случае это не "подсказка", а строгий контроль: скрипт упадёт с ошибкой если в первом примере в метод придет что-то отличное от класса реализующего интерфейс Foo, а во втором - если метод вернет что-то отличное от такого класса.

Контроль типов надо использовать, чтобы твой код был чище и работал предсказуемее.

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

Вот вам 12 маленьких задач на 12 паттернов:
github.com/zfcampus/zendcon-design-patterns

1. Открываете папку с паттерном.
2. Читаете README.md с описание задачи.
3. Открываете exercise.php и пытаетесь решить задачу, применив соответствующий паттерн.
4. При необходимости вспоминаете теорию: github.com/domnikl/DesignPatternsPHP
5. Сверяетесь с решением в solution.php.

В примере ниже, метод makeInterviewer(): Interviewer возвращает тип интерфейса Interviewer.

Этот метод ничего не возвращает, а только объявляет требования к наследникам - они должны реализовать этот абстрактный метод и уже вернуть конкретный объект, реализующий интерфейс Interviewer.

Соответственно, никакой магии тут нет, просто в вашем примере не хватает классов-наследников с конкретной реализацией.

interface Interviewer {
    public function askQuestions();
}

abstract class HiringManager {
    abstract public function makeInterviewer(): Interviewer;

    public function takeInterview() {
        $interviewer = $this->makeInterviewer();
        $interviewer->askQuestions();
    }
}

class TeamLead implements Interviewer {
  public function askQuestions() {
    ...
  }
}

class Boss extends HiringManager {
  public function makeInterviewer(): Interviewer {
    return new TeamLead();
  }
}

https://www.php.net/manual/ru/language.oop5.abstra...

Возвращает не "тип интерфейса", а должен возвращать объект класса реализующий интерфейс Interviewer.
Следовательно он точно должен содержать в себе метод askQuestions.
Вроде бы паттерн Strategy, но это не точно

знать нужно и то, и другое.
и третье-четвертое не помешает: иллюстратор, корел
и zeplin

ну, варианта два:
- иметь два реакт-приложения на странице, инициализируя их в разных контейнерах
- приводить к одной архитектуре и структуре для начала.

второй подразумевает что надо переделать так чтобы сборка была одна на всех и использовались те же версии библиотек, как минимум реакта и всех "глобальных" вещей, типа роутинга, gql если есть и тп. все что имеет глобальный стейт или использует контекст реакта.
подключайте как исходный код - будет проще изменить то что нужно изменить, отдельный модуль вам не нужен

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

Выбирайте любой вариант.

<script src="{{ asset("js/jsssss.js") }}"></script>
<script src="{{ URL::asset("js/jsssss.js") }}"></script>
<script src="/js/jsssss.js"></script>

Аналогично и с css:

<link rel="stylesheet" href="{{ asset("css/csssss.css") }}">
<link rel="stylesheet" href="{{ URL::asset("css/csssss.css") }}">
<link rel="stylesheet" href="/css/csssss.css">

В данном примере файлы находятся в public/js и public/css. Можете любой уровень вложенности делать, но так, чтобы всё это было внутри папки public.

Всё, кроме того что советуют учить по теме: «Что учить новичку в 2020?»

Без проблем. Не нравится - не изучайте.
Только будьте готовы что 97% всех вакансий/проектов пройдут мимо вас, потому что там верстка будет нужна.
Но вам никто не может запретить попытаться найти остальные 3% и среди этих 3% попытаться найти что-то стоящее.

В самом вверху явно карусель или слайдер.
Поищите jQuery скрипты карусели.
Например,
flexslider.woothemes.com/thumbnail-slider.html
А ниже обычные блоки с фотками по 3 штучки в ряд.

Реализовать можно по разному. Если через виз. редактор, то можно взять Visual Composer || WP Bakery Page Builder и подобрать виджеты для карусели.

Или взять вышеуказанный скрипт + кастомные поля ACF.
А сетку с 3-мя картинками в ряд можно например, при помощи повторителя ACF.
Добавить повторитель (для секции) и поля - заголовок секции (тип поля текст) + 3 картинки (тип поля - галерея)

в настройках "Постоянные ссылки" - "Произвольно" пишете /%category%/%postname%/

1) Делать проекты один за одним;
2) Повторяющиеся логику выносить в свои компоненты для переиспользования;
3) Держать шаблоны для типовых задач;
4) Использовать готовые компоненты. Тех же админок до кучи выбирай на свой вкус от Nova до сотен поделий индивидуальных разработчиков. Или oauth, когда нужен не свой писать, а использовать passport и т. д.

Сделать заготовку и отправить в Git.

Было такое. Это "рука не набита", приём не на какую-то технологию, а на сам принцип разбирания ошибок и поиск решения. Придёт с опытом.