RvRedd

Несколько общих соображений:

1. Если проект развивается, и вы не переписываете что-то уже готовое, то на начальном этапе нет смысла сильно заморачиваться со структурой. Просто делайте своевременно рефакторинг и приводите структуру к более удобному виду по мере развития.
2. По опыту более удобно все-таки иметь более плоскую структуру папок, иначе со временем по ним очень тяжело делать навигацию.
3. В вашем варианте вы получите много одинаковых файлов index и menu например. Как правило в редакторе открыта куча файлов, для названия остается мало места и у вас будет множество вкладок index.vue в итоге. Т.е. лучше делать название файла более информативным типа:

header\
HeaderLayout.vue (или Header.vue или HeaderBase.vue ) - базовый компонент, который так или иначе использует другие.
HeaderMenu.vue
HeaderTitle.vue
и т.д.

Лично я обычно имя компонента делаю равным имени файла.
4. Если не смотрели, стоит прочитать style guide по vue: https://vuejs.org/v2/style-guide/
5. Тесно связанные файлы и папки лучше держать ближе к друг другу для упрощения поиска.
6. Для базовых компонентов, чтобы отличать их от компонентов фреймворка например, можете сделать свой префикс типа app-button, app-selector и т.д.

На самом деле всё довольно просто. Можно пойти двумя путями:
1) Создать функцию внутри метода и вызывать её. Простой и удобный способ. Не захламляется класс и не нужно создавать никаких параметров для метода

slidesNavigation() {
  // твой метод, в котором уже есть код
  ...

  // заменяешь повторяющийся фрагмент на вызов функции
  toggleDotClasses();

  // функция, в которую завёрнут часто повторяющийся фрагмент
  function toggleDotClasses() {
    sliderDots[indexItemPrev].classList.remove('active');
    indexItemPrev = indexItem;
    sliderDots[indexItem].classList.add('active');
  }
}

2) Создать новый метод в классе. Так стоит сделать, если есть как минимум подозрение, что этот твой метод может потребоваться в других методах кроме slidesNavigation

class PortfolioSlider {
  ...

  // новый метод класса. нижнее подчеркивание намекает на то, что метод как бы приватный (служебный)
  _toggleDotClasses(sliderDots, indexItemPrev, indexItem) {
    sliderDots[indexItemPrev].classList.remove('active');
    indexItemPrev = indexItem;
    sliderDots[indexItem].classList.add('active');
  }

  slidesNavigation () {
    this._toggleDotClasses(sliderDots, indexItemPrev, indexItem);
  }
}

На мой взгляд лучше использовать первый вариант. В текущей реализации класса второй вариант не очень удобен

C телефона было сложно, но примерно так:


Как правильно отметил Brad9aga в своем примере, лучше первую и последнюю полоски сдвигать, так лучше выглядит:

Такое ощущение, что некоторые, кто тут дает ответы сам версткой толком не занимается. Дивы стандартные блоки, которые используются там, где нет возможности применить семантические теги. В любых иных случаях должны быть применены семантические теги. Это необходимо для поисковиков и для читабельности вашего кода. Таков стандарт html 5. Если вы не хотите соответствовать современным общепринятым стандартам, вы можете верстать хоть таблицами, но будте готовы к понижению позиций своего ресурса в поисковой выдаче, так же вряд ли кому то в дальнейшем понравится сопровождать ваш код. Вешать классы для семантики на дивы имея семантические теги признак отсталости и непрофессионализма. Так может сделать бэкендер или какой-нибудь фуллстак, но не уважающий себя фронт.

Ну такое совсем просто делается. Много стилей не надо. Достаточно fieldset, legend и чуть чуть transform

<fieldset>
  <legend>Легенда</legend>
  <p>Ну такое совсем просто делается. Много стилей не надо.</p>
</fieldset>

fieldset {
  transform: rotateX(180deg);
}

legend {
  transform: rotateX(180deg);
}

p {
  transform: rotateX(180deg);
}

Ты веcь такой кругом молодец, то знаешь, это знаешь. А теперь представь себе среднестатистический проект, который должен приносить бизнесу деньги. За две недели работы ты едва напишешь хлипкий CRUD для данных, неправильно смаппив бизнес-сущности в объекты ORM, ещё через месяц натянешь какой-то слайдер на jQ, попутно захватив 2мб JS кривых библиотек, а через два заказчик поставит тебе плохую оценку, потому что твой ценник он оплатил не за то, что ему нужно, а потому что ты знаешь монады, которые ему даром не сдались.

А теперь давай представим простого программиста. Из алгоритмов он с трудом вспоминает сортировку пузырьком, а двусвязный список — предел его знаний о структурах данных, и даже этим списком он пользовался два раза в жизни. Хаскель он никогда не видел в глаза, C++ учил только в школе, вместо этого пишет неэффективный код на PHP. И у него есть опыт. За день он распишет сущности, за второй сделает универсальный CRUD, на третий день поднимет фронт на React'е с SSR. Да, внутренности проекта будут "медленными". Вместо O(logN) что-то будет выполняться за O(N) или даже O(N^2), но всем похер. Пока всё работает на приемлемом уровне — бизнес радуется.

Кстати, к чему эта поучительная лапша? Я хотел сказать, что всеми этими модными словами можно пугать друзей и преподавателей, но в реальной жизни все алгоритмы уже реализованы, все типы данных уже подобраны оптимально. Знать их полезно для себя (чтобы мозг не атрофировался), но не для работы. Для работы тебе нужны такие навыки как:

* Оптимальный баланс между говнокодом и идеальным кодом
* Оптимальный баланс между скоростью разработки и оптимизацией кода
* Оптимальный баланс между поддерживаемым кодом и костылями
* Умение использовать те инструменты, с которыми ты работаешь. Опять же, для того, чтобы писать быстро, при этом имея минимальное количество говнокода и обеспечивая максимальную поддерживаемость (в пределах сроков). Например, можешь выкинуть в помойку свой Vim, как бы круто ты себя не чувствовал, разрабатывая в консольном редакторе, если продукты от JetBrains позволят за это же время сделать что-то лучше или чего-то больше
* Чувство "знаю больше менеджеров". Это то чувство, когда тебе кажется, что "вот эта фича скоро изменится" и надо сделать архитектуру заранее более гибкой. Или "вот эту фичу мы через месяц выпилим" и не надо тратить на неё силы — напиши костыль и через месяц с чистой совестью удали его
* Знания, как сделать ту или иную фичу. Потому что фичи повторяются (немного видоизменяясь) от проекта к проекту. И если ты сделал что-то за два дня, в следующий раз ты похожее сделаешь за три часа

Что касается инструментов, выбери любой полноценный фреймворк, который умеет решать 90%+ потребностей "из коробки": Symfony, Django, Laravel

Всякие "минималистичные" поделия вроде Falcon, Flask (в PHP не знаю, я на питоне пишу) оставь хипстерам. Пусть они говорят: "Мой фалкон такой быстрый, он написан на Cython". Тебя это не должно волновать, потому что бизнес с твоей скоростью разработки уже заработал достаточно денег, чтобы купить ещё десять серверов, пока фалконисты неделю гуглили, как прикрутить миграциии и запустить юнит-тесты на VPSке за пять баксов.

Зачем бутстрап? Можно и так быстро сделать: