Дима Паутов

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

без колупания package.json

а зачем его "колупать"? Его особо то и не трогают. Описал пару комманд, необходимых для работы и забыл.

v-model не подходит для такого и стоит пользоваться @change получая fileList?

Именно так

const uniqueArr = arr.filter((a, i) => arr.findIndex((s) => a.name === s.name) === i);

Гугл

так может свойство colorзаменить на backgroundColor?

а так же заменить это:
v-for="(index, bgColor) in colorArray"

на это
v-for="(bgColor, index) in colorArray"

Свайпер можно кастомизировать, взяв из него то, что вам нужно.

Вот выдержка из доки:
https://swiperjs.com/get-started

import Swiper, { Navigation, Pagination } from 'swiper';
  // import Swiper and modules styles
  import 'swiper/css';
  import 'swiper/css/navigation';
  import 'swiper/css/pagination';

  // init Swiper:
  const swiper = new Swiper('.swiper', {
    // configure Swiper to use modules
    modules: [Navigation, Pagination],
    ...
  });

тот или иной фреймворк решает различные задачи,

Если имеются ввиду angular, react, vue - чушь это всё собачья. Решают они одни и те же задачи, просто разными методами и философиями.

А что вы хотите услышать?

Каким образом вы выбираете себе автомобиль? Их так много, но все они решают одну и ту же задачу. Vue и React - это как мерседес и BMW. Вечное противостояние 2х философий. Обе машины прекрасны, дороги и комфортны, но у каждой так или иначе своя философия.

Берите то, что нравится. Просто возьмите все 3 и используя стандартные CLI, напишите обыкновенный бложек с созданием, редактированием, удалением записей, детальной страницей, т.е. обыкновенный CRUD. И посмотрите, с каким из них, вам процесс работы нравится больше. Потратить пару дней и всё.

Один спец. скажет вам, что реакт, другой скажет, что vue.
Третий скажет, что реакт это вообще даунгрейд по сравнению с vue(и тут я согласен).
Четвёртый скажет, что реакт для мужиков, на него больше вакансий, они дороже и проще найти работу.
Пятый скажет, что на реакте есть куча всяких штучек дручек и т.п.
Шестой будет молчать, т.к. юзает ангуляр и не знает никаких проблем и с насмешкой смотрит на этих 2х. Потому что это ещё одна, совсем не похожая на других философия. Где за тебя уже всё придумали, сделали и сказали как делать дальше.

Вы не получите полноценную картину.

От себя скажу так, если вы любите работать с html берите vue. Vue для меня гораздо лучше, чем react. В react гораздо больше писанины кода, чем в vue. Я терпеть не могу jsx(во vue он тоже есть), отвратительная штука, но это вкусовщина. Обязательно найдутся те, кто скажет иначе, ради бога. В vue шаблоны - это родной и привычный мне html с очень удобным и понятным шаблонизатором. Любите работать с html, вперёд.

Если вы не любите верстать и вам больше нравится сам процесс писанины js, писать стили на js, берите реакт.
Если вы любите типизацию, если вы за строгий контроль кода и вообще, вы считаете себя "тру" прогером, берите ангуляр, если коротко.

Заметьте, я чаще всего сравниваю react и vue, а ангулар где-то в стороне. angular - это как volvo, тебе ничего больше не нужно, у тебя и так всё хорошо.

window.innerWidth

Именно так и делать. 2 модели ModelInput на вход и ModelOutput на выход.
А ещё можно почитать про BFF, но это крайний случай, но он решает такие вопросы.

Но вообще, желательно договориться с бекендом о наименовании. Иначе, это на мой взгляд в большинстве своём "мусорный" код, который ничего не делает, а только раздувает пустым переименованием.

Постараться объяснить им, что вы ребята, работаете с json натацией, это ни к чему не обязывает, но всё же.
Что у меня, например, есть линтеры, которые не позволяют писать свойства с нижним подчёркиванием, тире.
Либо, я должен писать их так: obj['my_prop'] что не очень то.

Резюмируя:
1) Договориться, объяснить почему для вас это плохо и какие проблемы вызывает. И какие проблемы у вас могут от этого быть.
2) Делать свои модели для переименования
3) BFF
4) Забить болт, если это проходной проект.

P.S. Я убеждён, что json должен быть в camelCase натации. В своих проектах, я не раз убеждал бекенд команды делать так. Но это всё были новые проекты. Если проект уже старый, то тут точно ничего не подедать, либо BFF.

В большинстве случаев вы не ощутите разницы. А вот если вы работаете с огромным кол-вом элементов в выборке, разница может стать ощутимее.

Но по существу 1й вариант лучше.

Во 2м варианте, вы 2 раза заставляете искать элемент .parent, а в 1м варианте, кешируете результат поиска и повторно искать элемент уже не нужно. Если коротко и понятно

В новой, 6й версии кое что изменилось!

import { Switch, Route } from "react-router-dom";

заменить на

import { Routes ,Route } from 'react-router-dom';

Читайте документацию.

P.S. В гугле можно так забить было

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

Я как-то тоже задался этим вопросом, ибо частенько бывали подобные "персонализированные" рекламные интеграции. Конкретно доказать эту теорию самому себе я не смог. То работало, то не работало, то как-то странно это работало, толи мне казалось, что это работает вот прям так просто. Пробовал я простыми вещами, либо разговаривал с людьми на определённые темы, или хотя бы затрагивал их, по телефону, с друзьями по дискорду, телеге, просто когда интернет включён на телефоне, но лежит в кармане. Как и сказал, четкого следа нет)))

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

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

Помните, львиная доля выручки гугла - это реклама! А когда ты главный поисковик мира, более половины мира ходит с телефонами, где твоя OС, а если не твоя, то много где стоит хром, много ума не нужно, что бы начать действовать))) Гугл кстати не просто так платит эплу много миллиардов, что бы быть поисковиком по умолчанию в iOS)))

P.S. Лично мне по большому счёту всё равно. Зла эта штука не делает(пока), жить не мешает(пока), а иногда, действительно может попасться что нибудь интересное. Поживём, увидим)

https://jsfiddle.net/52trwn6L/

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

стоит вопрос делать его как 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 запрос или вывести кнопку с модальным окном и формой, потому что очень часто тупо юзают бутстрап и собрать подобные блоки просто, или же просто вывести новое поле с текстом или ещё чем-либо.
   
   

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