Дима Паутов

Проблема в том, что многие курсы рассказывают о различных web терминах, в
результате чего возникает каша, поскольку не знаешь где и что применять
Возьмём патерны проектирования, MVС, модуль и так далее. Насколько я понимаю они
и решают проблему разбивки кода...

В текущем, современном этапе разработки такими паттернами почти не пользуются. Сейчас у нас есть import/export - вот он ваш, нативный модуль. В остальном, просто положитесь на фреймворк.

Как подходить к оформлению кода, если мы не используем фреймворк Vue или иной...

Любой клиентский фреймворк - это уже своего рода архитектура, просто нужно следовать в начале пути общепринятым правилам. В отношении vue почитать про best practices. В этой папке компоненты, в этой папке сервисы, в этой папке утилиты, в этой папке типы и т.п. Разделяйте макет на части. Отдельный компонент фильтра, который состоит из множества компонентов самого фильтра, чекбокс фильтр, фильтр диапазона и т.п. Отдельно компонент товара и т.д.

Дмитрий Лаврик сказал, что бэкенд программисты в последнее
время создают API для сайтов. Так намного проще создавать бэк

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

Можно ли при помощи VUE создать fullstack приложения или без создания той же
структуры базы данны никак?

На vue нельзя написать фулстек, как и на react. Это браузерные фреймворки(клиентские), предназначенные для работы в браузере.

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

выучил JS на уровне решении задач средней сложности

Ну вам не кажется что из вышеперечисленного вами, вы не выучили js. Средней уровень сложности(хотя что можно считать "средним уровнем сложности" - это ещё вопрос), это наверно где-то джун+. А такие джуны уже умеют пользоваться инструментами.

Личный мой вывод:
Вы как и все начинающие окунулись в болото под названием js. Где царит хаос и анархия, когда можно всё, но не понятно как. У меня главный вопрос к таким людям, а зачем вам на данном этапе вашего развития "всё"? Ну вот серьёзно, зачем? Зачем вам сейчас знать, как устроена БД, как правильно создавать таблицы, как правильно создавать связи в них, зачем микросервисы, зачем, о госпади микрофронты, SSR, PWA, FullStack, Nodejs, Docker, Kubernetes, webpack, vite, TypeScript и прочая херня, которой полон мир фронтенда. Зачем вам всё это, если вы сами не можете ответить на этот вопрос. Зачем вам сейчас знать, как это работает. Если вы просто сайтик с чекбоксиками не можете сделать. Т.е. простая фильтрация html кода. Возьмите какую нибудь публичную rest api с фейковыми данными для своей песочницы и постройте маломальский сайтик с фильтром. Зачем вам фулстек? Почувствовать себя гением разработки? Забудьте про кучу не понятных терминов, просто выкиньте их из головы.
Зачем вам вообще vue или реакт, или им подобные? У вас в голове хоть есть понимание, зачем придуманы эти штуки, какую задачу то они призваны решать? Почему все так "дрочат" на эти SPA? Почему +- 90% вакансий фронта требуют знания SPA фреймворков? Каждый инструмент призван решать какую-то задачу, пока вы не поймёте, почему вам реально нужен этот инструмент, не трогайте его, пускай лежит до лучших времён.

Просто возьмите js или хрен с ним, возьмите vue, сделайте внутри ajax запрос, получите данные, отобразите их. Где в этих словах какие-то особенные или сложные термины? Вам идиоты напихали в голову сложных конструкций, вот вы и мучаетесь. Упростите себе жизнь, выкиньте из головы всякую хрень. Просто сядьте и пишите, не думая ни о чём! Просто берёте vue, разворачиваете как в доке написано и готово, работайте.
А когда сделаете, перекурите, а потом сядьте и посмотрите на своё творение и подумайте, как можно улучшить, возможно упростить. Не ждите быстрого успеха!

КОВАТЬ, КОВАТЬ И ЕЩЁ РАЗ КОВАТЬ! Только так можно научиться.

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

https://developer.mozilla.org/ru/docs/Web/API/Muta...

Никак, это же отдельный пакет!!! Если только сам модуль не позволяет изменение разметки.

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

Во первых, селектор не верный.
Было
div.owl-item active
Нада
div.owl-item.active

Во вторых, вы по всей видимости, используете слайдер owl-carousel.

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

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

Вам нужно прослушать событие у слайдера, которое символизирует, что слайдер проинициализирован и готов к работе. https://owlcarousel2.github.io/OwlCarousel2/docs/a..., а именно, судя по доке, вам нужно событие initialized.owl.carousel

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

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

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

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

Гугл

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

Вот выдержка из доки:
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],
    ...
  });

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м варианте, кешируете результат поиска и повторно искать элемент уже не нужно. Если коротко и понятно

Заменить

$.get('/api/getmap', {some:'test'}, function(response){

на

$.get('/api/getmap', {some:'test'}, (response) => {