Юрий

Возможно

осмысленное описание комита - маст хэв.
prj-3 - это говно, а не описание комита.

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

Как правильно определить, нужен ли префикс браузера в коде?

Алгоритм:
- Научиться пользоваться сборщиками проектов вроде gulp или webpack
- Не нужно лезть руками на caniuse и искать каждое свойство, этим занимется плагин autoprefixer, который на автомате, в зависимости от настроек степени поддержки браузера будет ставить вам всё.


https://webdesign-master.ru/blog/tools/gulp-4-less...

Зависит от компании и её рода деятельности.

Есть веб студии, клипающие сайты.
Есть компании, которые разрабатывают и поддерживают свои продукты\сервисы.

Работа в таких компаниях очень и очень разная.

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

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

Самые распространенные задачи front-end программиста:

• Отправка форм, фильтры, обратная связь и подобные, авторизация, регистрация и т.п.
  
  
• Работа с api - CRUD, чаще всего это REST API.
  
  
• Обработка и последующее отображение запрашиваемых данных из api
  
  
• Рефакторинг, оптимизации. Чаще всего делаются, если есть лишнее время и реальная нужда, а не рефакторинг ради рефакторинга
  
  
• Покрытие тестами. Как бы это не рекламировалось всеми и вся, делают далеко не все, я в их числе. Во многом считаю бесполезной тратой времени. Но тут моё мнение, оно не обязательно к обсуждению
  
  
• Изучение новых подходов, библиотек, инструментов и их возможное дальнейшее применение. Всё зависит от задач и проектов в целом, а так же самих компаний. Бывают компании, которые не любят программиста сидящего на одном месте. Потому как во многом, разработчики создают и улучшают продукт. Разрабатывая и внедряя различные инструменты, подходы, упрощающие жизнь при разработке или работе с проектами.
  
  
• Оценка входящих задач или новых проектов
  
  
• Болтовня с менеджерами, иногда занимающая от 20-30% рабочего времени, либо просто обсуждение задач и их решений с коллегами.
  

P.S. Не стоит думать, что новомодные фреймворки, SPA сайты применяют все кому не лень. Потому как перейти на такой формат - это титанический труд и обучение как людей, так и менеджеров. А проблем в этом подходе предостаточно. Ещё огромное кол-во компаний которые делают всё по старинке и не хотят переходить на новые тенденции в разработке. Во многом будут правы. Так же, бывает так, что под фронтенд разработчиком, компания понимает человека, который верстает, знает jquery и нужен им, что бы разгребать всякие легаси проекты без документации и без какой либо информации об устройстве проекта. Не забывайте внимательно изучать компанию, в которую хотите устроиться. Узнавайте у них о их стеке технологий, принципах разработки и конкретно ваших обязанностей. Т.к. бывает, что фронтенд разработчик ещё и должен уметь верстать. Тут я согласен, это в его компетенциях и обязанностях, но есть люди, кто с этим не согласен, это их право.

Можно сделать объект, у которого будет определено преобразование в примитив, изменяющее состояние объекта, от которого его примитивное представление зависит:

const obj = {
  val: 1,
  valueOf() {
    return this.val ^= 1;
  },
};

// или

const obj = {
  val: '1',
  toString() {
    return this.val = '1'.slice(this.val.length);
  },
};

// или

const obj = {
  val: true,
  [Symbol.toPrimitive]() {
    return this.val = !this.val;
  },
};

console.log(obj == false, obj == true); // true true
console.log(...Array.from({ length: 5 }, () => +obj)); // 0 1 0 1 0

Курить до просветления

Button - переводится как "Кнопка".
Отсюда простой вывод — используем везде, где нужна кнопка.
Если вы используете вместо кнопки div или span — это всегда неправильно.
Так же и ссылки. Если ссылка в макете выглядит как кнопка, то она все же остается ссылкой и верстается тегом а.

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

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

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

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

На пример: Форма. Общие стили формы -- критичный CSS. А стили для отображения условного попапа с подтверждением отправки -- не критичный. В результате, браузер скачивает критичный CSS, отображает страницу, пользователь уже может с ней работать и заполнять форму, а браузер в фоне дозагружает остальной CSS для попапа.

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

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

function round45(value) {
  return Math.round(value / 45) * 45;
}
round45(90.3222341); // 90
round45(136.99); // 135
round45(358); // 360
round45(46); // 45

По одному работает, если отметить оба, то "Error in v-on handler: "TypeError: Cannot convert undefined or null to object"

Что возвращает validations, если оба значения true? Ничего. Пусть всегда будет объект:

validations() {
  return {
    life: this.property ? {} : { required: v => v },
    property: this.life ? {} : { required: v => v },
  };
},

<div>STATUS: {{ $v.$invalid ? 'ЖОПА' : 'OK' }}</div>

Псевдокласс :empty

Поддержка браузерами

Это "сложение" (не сложение) работает только для целых чисел >= 0.

Если передать в Array одно число, будет создан (будет попытка создания - отрицательные и нецелые числа приведут к ошибке) массив указанной длины. Метод push может принимать несколько значений, а возвращает - новую длину массива, после добавления элементов. Т.е., в массив из трёх элементов добавили ещё четыре, и получили длину.