Veras IT

2022-07-07 09:08:21 Ускоряем LCP
LCP - Largest Contentful Paint или же отрисовка самого большого контента. Довольно простая метрика для оптимизации и ниже вы узнаете как можно получить сотку в lighthouse ускорить LCP.

Тут важно сразу внести ясность между метриками LCP и FCP (First Contentful Paint). FCP замеряет сколько прошло времени между переходом по ссылке появлением первого элемента на странице, а LCP измеряет время полной загрузки самого большого элемента в области просмотра

Самые частые причины плохого LCP - это медленное время ответа сервера, блокирующий рендеринг css и js , рендеринг на клиенте и медленное время загрузки ресурсов. В этом посте подробно рассмотрим загрузку ресурсов, а именно контента.

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

Какие же у нас есть варианты - , в
Самыми быстрыми будет обычный и poster в

2022-07-03 18:05:14 Что такое Vite и зачем он нужен

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

Vite становится одни из решений этой задачи. Он использует esbild , что позволяет ему быть в десятки раз быстрее вебпапака. То есть быстрее собирать проект и быстрее пересобираться в дев режиме. Так же целью vite является использованием нативных ES модулей в браузере, что позволяет разбивать бандл на модули и загружать только те модули, что нужны именно в данный момент.

Нельзя не отметить, что уже давно существует тенденция написания/переписывание инструментов для js на другие языки, которые делает это в 10-100 раз быстрее. Открыть/Комментировать

2022-07-01 16:10:11 Как правильно добавлять библиотеку на фронте

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

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

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

Так же тут важно следить не только за весом скачиваемого пакета, но и на его возможные зависимости. Не надо тянуть весь jquery ради плагина маски инпута :)

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

При добавлении библиотеки важно помнить, что это не ваш код и в не можете на него влиять, поэтому всегда стоит делать это очень ответственно. Иначе рискуете получить тяжелое и забаганное приложение/сайт. Открыть/Комментировать

2022-06-28 21:07:40 Хороший нейминг

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

1. Легко произносимые и легкие для поиска. Имена не должны быть аббревиатурами (только если часть имени ей является), сокращениями. Переменная должна легко читаться как наши обычные разговорные слова.

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

3. Возвращаться к переименованию. Тот же WebStorm позволяет довольно безболезненно переименовывать что либо в сразу в нескольких местах и не сломать код. Поэтому не стоит бояться возвращаться к переименованию , ведь у нас программистов ничего *ничего не получается с первого раза*.

4. Не боятся длинных имен. Конечно короткое и просто имя лучше сложного и длинного, но если короткое имя дать не получается и требуются некоторые уточнения - смело пишите их. Но тут тонкая грань, т.к. важно не дезинформировать (в первую очередь самого себя) нашего будущего читателя кода.

Это лишь некоторые из возможных советов по именованию. Самое главное - не делать это на автомате. Открыть/Комментировать

2022-06-26 19:16:46 Принцип единой ответственности (SRP)

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

Дядюшка Боб сформулировал этот принцип как нельзя лучше - "Модуль должен отвечать за одного и только за одного актора".
Тут могут внести неясность два слова - модуль и актор.

Модулем может являться что угодно, класс, объект, какая-то обособленная часть кода. И этот модуль у нас у нас отвечает за какое-то определенное действие.
Актор - причина для изменений данного кода.

Для понимания лучше всего привести пример с нарушением принципа SRP:


class CarDrive {
driveStraight() {
...
}

openGarage() {
...
}
}

Мы видим, что причин для изменения данного класса две - изменения в автомобиле и изменения в гараже. Это явное нарушение принципа. Конечно же для гаража надо создавать отдельный класс с методами, относящимися только к нему. Открыть/Комментировать

2022-06-23 21:28:42 Фильтры vue.js

Этой фичи как правило нет в обучающих курсах во vue, но я ее считаю вполне себе юзабельной. Взглянув на код всё станет понятно без лишних слов.

Пишутся они довольно просто:

vue.js
filters: {
capitalize(value) {
return value.charAt(0).toUpperCase() + value.slice(1)
},
},

И соответственно в шаблоне:

{{ text | uppercase }}

Так же фильтры можно применять при передаче данных в пропсы и делать чейнинг. То есть применять фильтры друг за другом:

{{ text | uppercase | lowercase }}

Очень удобная альтернатива methods или computed свойствам. Открыть/Комментировать

2022-06-20 21:56:30 (продолжение)
Пояснения к коду

От этого тоже лучше отказаться, но если всё же код не очень понятен, то лучше писать не что делает код, а для чего. Ведь скорее изменится сам код и его логика , а не то для чего это делается.

Для себя вижу только вижу только две ситуации когда комментарии точно оправданы.

Первая - это фикс неочевидного бага, когда требуется какая-то контринтуитивная реализация и нужно чтоб эту часть кода никто не трогал.

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

2022-06-20 21:56:07 Как же быть с комментариями в коде

Это довольно важная тема , т.к. комментарии с некоторой периодичностью встречаются в коде и они могут иметь как хорошее, так и плохое влияние при чтении кода.

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

Пройдемся по видам комментариев и как их лучше всего (не) писать .

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

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

2022-06-18 18:39:03 Лучший плагин для программиста

Современные IDEA, в частности webstorm, полны всевозможных инструментов помогающих писать код, избегать ошибок и придеживаться стиля написания кода. И вот еще один плагин, который я бы советовал установить всем и каждому - SonarLint.

Этот плагин не сколько про ошибки, сколько про качество кода, за чем уследить еще сложнее. Плагин актуален для большинства IDEA и языков программирования. По сути это огромный сборник правил, на которые и проверяет код. Он не только подскажет что за ошибка, но и скажет насколько она критична и как можно подойти к ее решению.

Особенно это актуально новичкам, т.к. он поможет уследить за сложностью и не написать "говнокод". Открыть/Комментировать

2022-06-15 19:14:07 Кто такой этот микрофронтед

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

Актуальна эта история для очень больших приложений, поэтому не везде этот подход стоит использовать.

Какие же есть плюсы у микрофронтенда:

- Возможность работы нескольких команд над приложением
- Легкая маштабируемость
- Изолированность кода
- Более легкое и внедрение фич и их дебаг

Минусы:

- Всё-таки нужна прослойка для объединения всех компонентов
- Проблема общих ресурсов (пакетов) и выполняется всё в одной среде (браузере)

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