Сергей delphinpro

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

Правильней будет перед перемещением папки .git воспользоваться командой filter-repo, чтобы пересобрать заново все предыдущие коммиты так, как будто репозиторий изначально лежал в корне.

Исходная структура папок

public_html
└── wp-content
    ├── plugins
    │   └── my_plugin
    └── themes
        └── child-theme
            └── .git

Подготовим старый репозиторий к перемещению

git filter-repo --to-subdirectory-filter wp-content/themes/child-theme

Получим такую структуру

public_html
└── wp-content
    ├── plugins
    │   └── my_plugin
    └── themes
        └── child-theme
            ├── .git
            └── wp-content
                └── themes
                    └── child-theme

Затем перенесём папку .git и всё остальное содержимое папки child-theme в корень сайта.

Мода есть, несомненно, но не только в ней дело!

стоит вопрос делать его как SPA на Nuxt или как обычный сайт с перезагрузкой страниц

Зависит от бекенда, если бекенд делает для вас api, тогда вам только SPA(не важно на чём), а если по старинке, значит по старинке, с перезагрузкой страниц. Тут как договоритесь.

Плюсы подхода разделения бека и фронта аля SPA:

1. Само по себе разделение ответственности. Фронт отвечает за отображение, бек за данные. В этом их суть
   
   
2. Удобство работы. Вы работаете исключительной с той кодовой базой, которая вам понятна, приятна.
   
   
3. Отдельные репозитории. Каждое окружение само решает, как им лучше вносить фичи, без оглядки на друг друга. Фронту не должно быть дела, до обновления фич и решения возможных конфликтов с бекендовым кодом. Вы работаете исключительно со своей кодовой базой
   
   
4. Сами по себе преимущества spa. Обновление только нужных участков html, более быстрое решение рутинных задач, за счёт автоматизации многих процессов аля(vue cli, nuxt и т.п. - там всё уже из коробки собирается и настроено, только пиши код), разделение кода на чанки и т.п., думаю и так понятно
   
   
5. Какая никакая, но архитектура приложения.
   Разворачивая проект через cli, вам уже даётся начальная структура папок, что уже говорит о том, что вам не нужно думать хотя бы об этом. Вы заранее знаете(если у вас есть опыт, если нету, ничто не поможет всё обговнять) что для решения тех или иных фич вам нужны те или те возможности фреймворка.
   Хоть реакт, хоть vue, уж тем более angular.
   
   

Минусы подхода разделения бека и фронта аля SPA:

1. Настройка всего деплоя приложения на сервере. Настроить gitlab.ci, настроить докер, настроить vps(если уже не готов), настройка nginx(не всегда, но бывает). Или вы думаете, за вас кто-то это будет делать? Бекенд себе всё настроит, а вы сами давайте. Вы же хотели разделение. Дай бог, что у вас в компании есть админ, который занимается подобными вопросами или же просто кореш, готовый вам помочь.
   
   
   
2. SEO - большая проблема нашего времени. Если SEO, значит ssr, раз ssr, значит nuxt(ну или ручками настраивать, удачи). Тогда тут вступает в силу node.js. Его бы на сервере ещё запустить, на порту повесить и т.п. Просто SPA собрал и всё, а вот SEO, SEO накидывает на нас гемора и работы.
   
   
   
3. Реализация "модулей" с 0, которые в старом подходе у бека уже можно скачать(из магазина готовых решений например, если это цмс, ну или готовые пакеты у фреймворков) и запустить(корзина товаров, фильтры, каталоги, сортировки и т.п. вещи). На фронте придётся всё делать заново, потому что готовых решений нет.
   
   Если взять какой нибудь вордпрес или битрикс, где уже имеется огромное кол-во готовых решений, которые подключил и они работают, минимально +- правя стили, то в spa подходе, дай бог что бы эти решения имели rest api для вашего чудо spa. А вы в свою очередь будете клипать вёрстку и логику с 0, мучаясь с кучей запросов, обновлением данных и т.п. вещами.
   
   А писать оформление заказа с выбором доставки, да и выбором адреса на карте, с последующим выбором кучи других моментов при оформлении заказа, это жесть. Но зато сами напишите, зато SPA, vue. А если ещё и авторизация какая-то будет, да и с заворотами или через какой-то внешний oauth сервер, так вообще красота)))
   
   
   
4. Сложность понимания, на чьей стороне произошла ошибка. Фронт всегда будет выступать в первых рядах. Все камни полетят к вам. Не вывелось то-то, фронт иди сюда, не отправилась форма, фрооооонт, ауууууу!!!!!
   А как винить за это менеджеров? Они не должны сидеть кликая f12 и анализируя, где и какая ошибка получилась.
   Иногда бек виноват, иногда фронт.
   
   Да, можно подключить какой нибудь sentry. Но это, на мой взгляд, лишь доказывает, что с наш подход усложняет поддержку и разработку. Теперь у нас появился ещё 1 сайт, где мы смотрим логи фронта, что же у него случилося. У бека всё просто, зашёл на страницу, бац, ошибка sql на всю страницу, всё ясно становится)))
   
   Я конечно это не вот прям серьёзно, но зерно то есть в этих словах. Sentry хорошая штука, но она станет незаменимой для решения этих проблем. Иначе понять, на чьей стороне происходят не понятные ошибки, которые не ясно как выявить, а логи у ноды лежат чёрти где, если вы или ваш админ не настроили их по людски.
   
   
   
5. Очень частая зависимость от данных бекенда. Изменилось 1 поле у бека, вам скорее всего нужно идти и править это. Добавилось новое поле, опять бежать и выводить 1 переменную. Мать твою, бек, сам не можешь что-ли переменную вывести??? Ах да, у нас же SPA.
   
   
   
6. Прикрываясь удобством и модностью SPA можно такого говна наворотить. Сделать компонентики любой дурак сможет, а вот создать хаос из этих компонентов и не понимая, как более менее внятно решать проблему серьёзных задач и организации кодовой базы, это да. Не все осознают, на что подписываются. Иначе вы бы не задавали такие вопросы.
   
   В то время, когда бы за вас всё бекенд делал, потому как многое у него уже готово, а вы просто вёрстку ему отдали бы и всё. Ну подвёрстывали бы иногда, ну пару скриптиков добавляли.
   
   
   
7. Ну и последнее, удорожание поддержки такого проекта. Т.к. вместо единой кодовой базы, теперь их 2. Внесение изменений требует большего кол-ва людей, нежели при обычном подходе. Бекендер и без фронта может написать jquery ajax запрос или вывести кнопку с модальным окном и формой, потому что очень часто тупо юзают бутстрап и собрать подобные блоки просто, или же просто вывести новое поле с текстом или ещё чем-либо.
   
   

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

scss формат синтаксиса для препроцессора sass. css.map - карта для исходников, генерируется сам, если "компилятор" позволяет. Благодаря ему, в devtools будет информация где прописаны стили в scss, а не в css.

Редактировать нужно scss, компилятор генерирует css и css.map (опционально). К странице подключается css через <link>

scss можно скомпилировать по разному, есть плагины для редакторов, отдельные программы, но это не удобно, потому-что если код нужно редактировать другому разработчику, то ему нужно настраивать соответствующее окружение. У большинства фронтендеров этим занимаются gulp, webpack или какие-то другие сборщики

Тут инпут только там, где единица. Остальное - тупо поле со сверстанными процентом и кнопками вверх\вниз, которые работают через js. Так что решение простое, верстаете как на макете, затем позиционированием вставляете слева реальный инпут. И останется в js кнопочки активировать, чтоб верхняя брала значение инпута, добавляла +1 и вставляла в инпут, а нижняя делала тоже самое, только -1. Вот и вся задача. Главное проверку добавьте, чтобы при -1 ниже нуля не опускалось значение.

Если сетка повторяющаяся то через nth-child задаете сколько строк и столбцов должны занимать элементы.
Если нет, то классы.

nth-child

классы

Никак не делать, эти переменные никому не мешают

Установить на ПК любой web-сервер, настроить его на раздачу нужных вам файлов, купить белый IP-адрес у провайдера, настроить проброс 80-го порта на домашнем маршрутизаторе, купить доменное имя у любого регистратора и прописать в A-запись доменной зоны ваш белый IP.

Я понимаю, что для вас такое поведение выглядит непонятным, но по названию вашего вопроса и тегу javascript легко догадаться о его содержимом не заходя внутрь. Просто потому, что ровно таких вопросов здесь повяляется по три в день.
Прочитайте как работает асинхронность в javascript, про промисы, про async/await.

Возможно, это нормально, так и должно быть ? или как архитектурно правильно решать подобное?

Это нормально. Безликие массивы становятся осмысленными сущностями. Такой код становится проще понимать и поддерживать.

Используемый вами подход называется data transfer object (DTO). Широко распространенная практика. DTO отлично сочетается с иммутабельностью, которая присутствует в ваших классах.

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

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

Называется ORM. Находится в ответственности ORM слоя/фреймворка.

м - минификация.

Слеши забыл экранировать