ewb

1. Используем препроцессор, любой: sass, less, stylus

2. Общие стили(все что используется или может использоваться часто) в общее.
Один файл точка входа, в него импортируется другие файлы с общими стилями.
Файлы с общими стилями, максимально разбиты, по назначению, разделам... Зависит от проекта. На огромных проэктах, можно дополнительно по подпапкам разбивать. Главное что бы удобно было в этом ориентироваться.

Все общие переменные обязательно в отдельный файл*
Все общие миксины обязательно в отдельный файл*
** Дает возможность быстро изменить препроцессор, если понадобится. У всех разные синтаксис переменных и миксинов

Если миксин статичный, без параметров, лучше заменить его на класс, например .some-mixin-class
И использовать его так:
.some-class {
@extend .some-mixin-class;
...
}
При этом .some-mixin-class нельзя использовать как обычный класс напримую, только экстендить в других классах

@extend .some-mixin-class - Работает одинаково во всех препроцессорах и хорошо читается

Все общие стили только по БЕМ

3. Специфичные стили для компонента пишем в файле компонента.
Или scoped или БЕМ - как удобней
Если таких стилей очень много, то выносим в отдельный файл и импортируем в компаненте
В эти стили по необходимости(если нужно использовать) и импортируем файл с общими переменными или миксинами

Самое сложное, научится определять, что общее а что специфичное, это не объяснить. Приходит с опытом и постепенно

В Vue приложении используем препроцессор (scss). Кроме того используем внешние пакеты для вертикального ритма и сетки.

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

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

Что делаем:
Подключаем в точке входа (main.js) основной стилевой файл:

import '@/styles/main.scss';
import Vue from 'vue';
//...

В нем подключаем всякое-разное-глобальное-базовое:

@import "base/normalize";
@import "base/init";
@import "base/typography";
@import "base/code";
@import "base/links";
@import "base/tables";
@import "base/buttons";
@import "base/control-group";
@import "base/general-form";
@import "parts/transitions";
...

Далаем два файла: env-development.scss и env-production.scss

$NODE_ENV: development;
@import "cfg-vars";

$NODE_ENV: production;
@import "cfg-vars";

Переменная $NODE_ENV нам нужно. чтобы управлять стилями в зависимости от окружения.
Дальше в cfg-vars.scss подключаем/пишем все необходимые глобальные конфиги

$DEV_MODE: $NODE_ENV == development;
$MAX_INT32: 2147483647;

@import "cfg-vrhythm";
@import "cfg-grid";
@import "../../../node_modules/vrhythm/source/vrhythm";
@import "../../../node_modules/bs-grid-system/source/scss/bs-grid";
@import "../mixins";
@import "cfg-z-indexes";

$wt-family-base: "Open Sans", sans-serif;
$wt-family-head: "Roboto Slab", serif;
$font-family-monospace:  "Fira Code", Menlo, Monaco, Consolas, "Courier New", monospace;

//==
//== Color palette
//== ======================================= ==//

$palette-light-blue: #3c8dbc; // Primary
$palette-red       : #dd4b39; // Danger
$palette-green     : #00a65a; // Success
$palette-aqua      : #00c0ef; // Info
$palette-yellow    : #f39c12; // Warning

...

Почти всё готово. Осталось только автоматически подключить эти конфиги к сборке.
Идём в vue.config.js и добавляем секцию css:

const NODE_ENV = process.env.NODE_ENV === 'development'
    ? 'development'
    : 'production';
//...
module.exports = {
    //...
    css: {
        extract: NODE_ENV === 'production',
        loaderOptions: {
            sass: {
                data: `@import "@/styles/config/env-${NODE_ENV}.scss";`,
            },
        },
    },
};

Теперь мы спокойно пишем стили компонентов на scss прямо vue-файлах, и оставляем возможность какие-то стили писать в отдельных файлах.

Enjoy!

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

Что в вашем проекте главнее? что задает тон разработки, бакэнд или фронтэнд? Если бакэнд по сути прослойка к базе данных, то пусть за api отвечает фронтэндер, ведь для его удобства его разрабатываете, если же у приложения сложная бизнеслогика и сложное использование и несколько клиентов, то скорее всего тон разработки api должен задавать бакэндер.

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

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

Использовать конструкцию, типа:

const URL = process.env.NODE_ENV === 'development' ? 'localhost' : 'test.ru';

не самый лучший вариант, т. к. всё это (хоть и в uglify-виде) уедет на production.

Лучше сделать 2 отдельных файла и подключать их через alias webpack-a в зависимости от process.env.NODE_ENV
Тогда при production сборке в бандл попадет только нужный нам код без мусора.

Продуманная структура, автогенерация роутов, набор готовых модулей (авторизация, контент и так далее)

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

Все вышеперечисленные ораторы писали именно о XLS -> PHP
с XLS все на так просто… работал с множеством разных классов для парсинга… нет 100% работающего, из 500 файлов с компьютеров разных пользователей обязательно попадется файл в котором даты считаются как числовые значения или еще какой глюк.

а если смотреть на XLSX -> PHP я бы посоветовал сделать «свой велосипед»
1) распаковываем файл… (xlsx это обычный zip)
2) внутри будет xl/worksheets/sheet1.xml в котором уже ваши данные в читаемой форме

> - поиск среди всех прямых потомков.
+ - элемент, непосредственно идущий за данным.

<div id='l1_1'>
  <div id='l2_1'>
    <p id='l3'>
  </div>
  <p id='l2_2'>
</div>
<p id='l1_2'>
<p id='l1_3'>

#l1_1 > p соответствует элементу #l2_2
#l1_1 + p соответствует элементу #l1_2

Чтобы без труда поменять реализацию. Например выпустят разрабы нечто вроде Math.random_ex. Оно-то лучше, но не везде работает и менять везде по коду не удобно. А так - в одном месте сменил или if поставил и готово :)

Событие - это функция.

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

Так как это событие, то аргументы функции вы не контролируете. Остаётся только второй вариант. Третьего варианта не существует.

При хранении данных в глобальном пространстве остаётся вопрос способа хранения. Можно создавать отдельные глобальные переменные (ваш вариант 1), или можно хранить переменные в объектах DOM (ваш вариант 2). По сути DOM - это помощь вам в структурировании данных, ну суть та же, т.к. доступ через глобальную переменную (document).

Можно использовать промежуточный вариант. Создать глобальный объект { } - и в нём придумать свою структуру, какая вам будет удобна. Какие там будут идентификаторы, как осуществляться добавление данных и поиск - вам решать. Можете сделать всё красиво и удобно. Это как бы ваш личный неймспейс для конкретной фичи. От жёсткой структуры DOM вы будете независимы.

Общую часть похожих кусков кода превращаем в функцию, а то, чем они различаются, будем передавать в эту функцию в качестве параметров:

[
  [   'region_id',   'regionName' ],
  [ 'district_id', 'districtName' ],
  [     'area_id',     'areaName' ],
  [     'city_id',     'cityName' ],
  [    'place_id',     'cityName' ],
  [        'name',   'streetName' ],
].forEach(([ del, search ]) => {
  if (this.tableParam[del]) {
    delete this.tableParam[del];
    this.searchForm.get(search).patchValue(null);
  }
});

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

Судя по всему это тестовое или учебное задание. От вас требовалось отоверинжинирить простую задачу. Давайте попробуем:

Суть задачи - есть файл с определенной структурой хранения данных, структура строковая. Требуется этот файл преобразовать в другую структуру данных и вывести эту структуру в json формате. Задача ясна.

Разобъем задачу на отдельные независимые этапы:
1) Преобразование одной структуры данных (текстового файла) в другую (объект, понятный PHP, к примеру)
2) Преобразование этой структуры данных в Json формат.
Первый вопрос, который может возникнуть - почему сразу не преобразовать в json? Ответ - при расширении системы в будущем - нам понадобится вывести данные в виде массива, или в виде XML, или даже в виде готового файла Excel. Нам будет сложно дополнять логику изначального класса, ничего при этом не сломав и не затронув уже существующий функционал. Также ответом на этот вопрос может являться каждая буква из SOLID принципов, подробнее отвечу дальше, когда буду пояснять за реализацию, см. ниже

Теперь рассмотрим эту задачу с точки зрения ООП, начнем думать не от конкретной реализации, а от интерфейса и абстракции (мы не парсим конкретный файл, мы парсим просто файл, мы не переводим его в конкретное представление json, мы переводим его просто в представление):
Нам понадобится 2 класса - непосредственно класс, читающий файл и преобразующий его в простейший тип данных (например PHP array). Второй класс - преобразователь простейшего типа данных парсера в какой-то определенный тип:

1. LogFileReaded implements/extends FileReaderContract(интерфейс, возможно абстрактный класс, если понадобится предустановленная логика)
   
   Непосредственно наш преобразователь (не забываем, что передавать путь к файлу и все настройки нужно из вне, к примеру, в конструктор. Нельзя, как вы - хардкодить всё внутрь файла, на крайний случай - можно использовать конфигурацию), на ввод получает файл определенного типа с определенной известной структурой, на выходе выдает информацию из файла, преобразованную в базовый тип (массив, в нашем случае). Если нам когда-то понадобится парсить другой тип данных или структура данных будет изменена - мы сможем написать отдельный класс для этой логики, а не рушить целостность уже работающего кода, добавляя туда новую логику. Запомните - нужно стремиться не менять, а дополнять.
   
   
2. JsonPresenter implements/extends DataTypePresenterContract
   
   Абстракция содержит контракт на метод output(), а в конструкторе принимются исходные данные. В конкретной реализации JsonPresenter в output() будет банальный json_encode() (да, это нормально, нет, класс не лишний и нет, json_encode() нельзя пихать в сам парсер) А теперь к вопросу - почему не следует просто запихать это всё в парсер и вместо массива отдать json: в будущем, когда система будет расширяться - нам понадобится представить данные в виде XML - что тогда будем делать - переписывать весь код парсера ради добавления switch case "json" и т.д.? А если что-то сломается во всей системе? А если вариантов представления станет настолько много, что файл будет просто не читаем? А при данном подходе достаточно будет просто написать новый класс XMLPresenter, или даже ExcelPresenter, который на выводе не строку будет выдавать, а целый файл (опустим типизацию output пока)). Также этот класс можно реализовать в виде декоратора (паттерн), да и много еще как.
   
   

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

К примеру: в итоге, если вас уже повысили, и вы вместо парсинга стали заниматься более высшими материями - новому программисту, чтобы дописать логику преобразования данных в Excel не нужно знать как конкретно вы преобразовывали когда-то эти данные в json, ему не нужно дебажить ваш код, ему достаточно посмотреть на интерфейс - отнаследоваться от него и написать свой собственный метод преобразования и дальше использовать его в нужном месте.

P.S. В данной реализации опускаются и упрощаются некоторые моменты для понятности