Lyoha Plotinka

Как запретить коммит, если не поменялся определённый файл?

2021-09-13T19:12:52.464Z

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

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

И вот, решение: используя git-хуки мы можем сделать так, чтобы если в коммите нет какого-то файла (то есть, он не был изменён) — мы не разрешали сделать пуш. Так сказать, наводим твёрдый порядок жёсткой рукой! А то слишком удобно живётся.

Итак, речь пойдёт про окружение Linux и Mac. Предположим, что наш файл называется changeme.txt. Нам понадобится такой вот шелл-скрипт:

#!/bin/bash

changes=$(git diff --cached --name-only)

if [[ $changes == *"changeme.txt"* ]]; then
  exit 0;
else
  echo "ERROR: changeme.txt is not updated"
  exit 1;
fi

Теперь дадим ему разрешение выполняться:

chmod +x ./changeme-detect.sh

Ну а дальше дело за малым — с помощью какого-нибудь lint-staged или husky добавляем запуск этого скрипта на хук коммита.

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

Вот как-то так. Вам слишком удобно работается? Тогда добавляйте это в свой проект :)

Привет, мир!

2021-07-27T07:09:51.341Z

Меня зовут Лёха, если предпочитаете длинно — Алексей Соловьев. Я уже больше четырёх лет работаю в сфере JavaScript-разработки.

Я люблю JS, open-source и музыку. Ниже я оставлю несколько ссылок, которые могут быть полезны, чтобы узнать меня получше.

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

GitHub - https://github.com/lyohaplotinka
YouTube - https://www.youtube.com/channel/UCMxrWsJZGW3JO4TSeJg-NxA
Telegram - https://t.me/lyohajs
Music VK - https://vk.com/lyohaplotinka

Почему стоит отказаться от поддержки IE

2021-07-23T09:59:45.839Z

Предисловие

Я очень большой противник Internet Explorer. Всегда был таким, но к началу 2021 года стал ещё большим (хотя, казалось бы, куда уж).

Я решил написать коллегам по работе, что нам пора начинать предпринимать шаги к прекращению поддержки IE, и это не только для нас хорошо, но и для клиентов, и даже прежде всего — для клиентов. Чтобы не писать длинные простыни в мессенджере, я решил оформить эти доводы в отдельном файле.

Сейчас, немного отредактировав его, я решил его опубликовать.

Почему нам стоит отказаться от поддержки IE?

Коллеги, в конце прошлого года я понял, что хочу поднять одну важную тему, а именно — прекращение поддержки нашими сервисами отчётов браузера Internet Explorer, всех версий, даже 11. Если ещё год назад это можно было бы назвать «прихотью» фронтендеров, то сейчас это уже гораздо ближе к объективной необходимости.

Прежде всего, стоит обозначить, что такое «прекратить поддержку». В моём понимании это значит следующее: сервисы доступны в браузере, пользователь может взаимодействовать с ними на своё усмотрение, однако, в случае возникновения проблем мы не гарантируем их решение конкретно под этот браузер. Если коротко: хотите работать в IE — пожалуйста, но мы не гарантируем, что всё будет работать правильно.

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

Для пользователей: безопасность
В IE бесчисленное количество дыр безопасности, которые постоянно закрываются патчами разного уровня качества и забагованности. Последняя из них была обнаружена в августе 2020 года, и была довольно критичной (ссылка).
Мы можем быть уверены, что это не всё. До сих пор Microsoft выпускала обновления безопасности, однако, в скором времени они полностью прекратят его поддержку, а именно — 17-го августа этого года.
Уязвимости позволяют делать много «весёлого»: от кражи куков и данных карт до выполнения произвольного кода в контексте пользователя. К сожалению, мы тут ничем не можем помочь пользователям, ведь даже те патчи, которые выпускаются, устанавливают далеко не все.
Для пользователей: юзабилити
Наши панели отчётов использую большое количество стилизаций и фронтовой логики. На поддерживаемых JS-движках, вроде V8, SpiderMonkey, JavaScriptCore это не создаёт проблем, однако на движке Chakra, который используется в IE, возникают проблемы со скоростью работы. Если мы не готовы отказаться от интерактивности и перейти целиком на статику, мы не можем это изменить, никакие оптимизации это не изменят.
Для пользователей: отказ от поддержки другими компаниями
В 2021 году, помимо прекращения поддержки самого IE, его перестанут поддерживать сервисы Microsoft и Google. Речь, конечно, не про поиск, но про Gmail, Google Forms и прочие решения. YouTube уже отказался от поддержки IE (ссылка). Microsoft Teams, а также офисные пакеты, также прекратят поддержку IE в этом году (ссылка).
Для нас: скорость релизов
Новые фичи появляются у нас достаточно часто, и, естественно, мы должны поддерживать и Explorer. Часто в нём не работают кажущиеся очевидными вещи, которые должны работать даже в IE6. На «раскопки» уходит много времени, плюс ещё затраты на поиск фоллбэк-решения.
Для нас: генерация лишних задач
Немного связано с предыдущим пунктом. Часто возникают сверхсрочные задачи, суть которых в том, что какой-то простейший отчёт внезапно перестаёт работать в IE11. Использование IE уже ничем не оправдано из-за его небезопасности, о которой трубят все, и громче всех — Microsoft. Но мы не можем оставить клиента без оплаченной услуги, хоть и не хочется поощрять беспорядочные интернет-связи. Тем не менее, такие задачи действительно довольно срочные, и связаны с переключением внимания от других срочных.
Для нас: стагнация
Пожалуй, самый незначительный пункт, который я всё-таки хочу написать. Огромное количество легаси-кода, написанного в старом синтаксисе, усложняет любую задачу. Каждое изменение требует длительного тестирования и связывания рук самим себе. Нам недоступен новый синтаксис, нам недоступно развитие языка, а следовательно — мы неконкурентны, как профессионалы и сервис. Скиллы изящной деградации или прогрессивного улучшения важны, но применять это к Explorer потихоньку становится бессмысленно.

Это шесть причин, которые мне кажутся самыми важными.

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

1 марта 2021 г.
В сервисах для пользователей IE мы показываем уведомление, что с 1 июня мы прекращаем поддержку IE. Можно приложить ссылку на объяснение, что это значит и почему так происходит. Получается, что мы дадим пользователям 3 месяца на то, чтобы адаптироваться к чему-то другому. В середине марта как раз будет прекращена поддержка сервисов Google, и первый “удар” уже успеет ощутиться.
1 июня 2021 г.
В сервисах для пользователей IE мы показываем уведомление, что браузер не поддерживается. Мы не принимаем от клиентов задачи по “съехавшей” вёрстке, исправляя только критические white-screen баги, то есть, когда контент не виден вовсе.
1 сентября 2021 г.
Сервисы более не приспосабливаются для работы в IE. Все задачи от клиентов, связанные с совместимостью с ним, не принимаются.

На первый взгляд, такие действия могут показаться жёсткими (или жестокими), однако, как мне кажется, мы даём предостаточно времени для поиска другого решения.

Единственная проблема, которую я вижу — недовольство клиентов. К примеру, <коллега> мне как-то говорил, что в некоторых организациях “не разрешено ничего, кроме IE”. Прежде всего, хочу сказать, что это решение выглядит очень странным, и, честно говоря, неправдоподобным. Я знаю, что на гос- и окологоскорпорациях сейчас полным ходом идёт “импортозамещение”, и на многие компьютеры устанавливается Astra Linux, в котором IE нет и в помине. Там, где этого не происходит, ограничений на браузеры нет, особенно если речь про один из четырёх самых известных.

Если же это не так, то поддержка Windows 7 закончилась в январе 2020 года, а для более новых версий ОС есть Microsoft Edge, к которому никаких претензий нет. Для топ-менеджмента на устройствах Apple есть Safari.

Я уверен, что бояться “ухода” клиентов не стоит. Наши клиенты лояльны к нам и любят нас не за то, что могут смотреть отчёты в IE, я в этом уверен. К тому же, если не в этом году, то уже через пару лет им придётся уйти из всего интернета: тенденция к прекращению поддержки IE прослеживается очень чётко. Чтобы сгладить углы, нужно действовать постепенно: именно поэтому я и хочу разбить всё на три этапа.

React Native: побеждаем lineHeight кроссплатформенно

2021-07-23T09:58:41.231Z

React Native вызывает споры, но он определённо хорош двумя вещами: быстрый старт для веб-разрабов и кроссплатформенностью, то есть, пишете один раз - получаете приложение для Android и iOS сразу же.

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

Проблемы начинаются вместе с кастомизацией. Мало того, что добавить свой шрифт в RN-приложение непросто, ещё и начинаются проблемы с тем, как текст с этим шрифтом выглядит.

А как вообще использовать свой шрифт?

Про добавление самого файла шрифта есть много публикаций в Интернете (к примеру, хорошо написано вот тут).

Но просто добавить файлы недостаточно. Здесь стоит сказать следующее: React Native немного ломает привычный флоу работы с HTML и CSS, что вполне логично. Лично мне это показалось диким и непривычным, но, чем раньше вы поймёте, что иначе никак - тем лучше :)

Самый простой вариант - написать свой компонент, наследуемый от Text. Я в своём проекте использую библиотеку компонентов Native Base, так что покажу на её примере.

Итак, я добавил файлы шрифта Gotham Pro, теперь время написать компонент:

import React from 'react'
import { Text } from 'native-base'

export const MyText = (props) => {
  const style = {
    fontFamily: 'GothamPro',
  }
  return <Text {...props} style={style} />
}

Смотрим - шрифт правильный. Однако в дальнейшей работе вы увидите, что высота строки на iOS и Android различается.

Источник: https://stackoverflow.com/questions/47925577/different-lineheight-on-android-ios-using-react-native

Исправляем высоту строки

Это происходит из-за того, что дефолтные величины, используемые для настройки таких свойств, как lineHeight, на iOS и Android с виду одинаковые, но работают чуть-чуть по-разному. Значит, нам нужно явно указать, какой lineHeight должен использоваться сейчас.

Обновим компонент:

import React from 'react'
import { Text } from 'native-base'

export const MyText = (props) => {
  const fontSize = props?.style?.fontSize ?? 16
  const lineHeight = props?.style?.lineHeight ?? fontSize
  const style = {
    ...props.style,
    fontFamily: 'GothamPro',
    fontSize,
    lineHeight
  }
  return <Text {...props} style={style} />
}

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

Этот компонент позволяет нам “пробрасывать” стили, а также вручную управлять высотой строки и размером шрифта. Однако, если же мы хотим просто вывести текст - наш не ждёт никаких разочарований: текст будет выглядеть одинаково и на iOS, и на Android.

Не очень красиво…

Вам тоже показалось, что решение не очень-то изящное? Что ж, React Native - костыльная штука, которая позволяет делать многое, зная что-то одно. За то, что я ленюсь изучить нативную разработку, я плачу костылями. Пока что мне это подходит. А вам? :)

Пишем компилируемый сервер на JS

2021-07-22T10:01:49.541Z

Ситуация прямо сейчас

Согласитесь, то, что JS подходит не только для браузера - уже не новость. С появлением Node.js мы все поняли, что JS, как и любой другой язык, всего лишь инструмент, а как его использовать - дело фантазии, ну и, пожалуй, API.

Спустя десять с лишним лет ситуация на поле серверного JS изменилась несущественно. Основные пути использования - Node и Deno, для любителей особых ощущений - fpm-решения.

Болячки Node известны всем. Deno частично решает их, но остаётся всё тем же наследником, перенося некоторые непонятные решения. К примеру, когда я смотрел последний релиз Deno, в котором появилась команда deno compile, я был удивлён тем, что на выходе мы получаем бинарник размером ~36 мегабайт. В Node же есть только костыльные сторонние решения, которые чаще всего приводят к тому, что ваше приложение либо не собирается, либо не работает после сборки, из-за того, что какие-то модули не найдены.

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

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

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

Фабрис Беллар и QuickJS

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

Эмулятор QEMU;
C-компилятор Tiny C Compiler;
Конечно же, FFmpeg;
Конечно же, Git.

В 2019 году к этому списку прибавилась ещё одна интересная вещица: рантайм для JavaScript, написанный на C, не использующий AST и обеспечивающий практически бесшовную интеграцию со всякими POSIX-штуками — QuickJS.

На своем сайте Беллар называет QJS “маленьким встраиваемым движком JavaScript”. Это действительно так: полный размер движка всего 620 килобайт, при этом он поддерживает практически все стандарты ES2020.

Всё это здорово, но давайте трезвым взглядом посмотрим на то, чем QJS является прямо сейчас:

Это довольно быстрый маленький JS-движок, способный составить конкуренцию даже V8 (но без JIT);
Это полная поддержка ES2020, но не без странностей. К примеру, вывод объектов в консоль покажет вам только [object Object];
Это очень скудная стандартная библиотека. Фактически, всё, что вы можете - взаимодействовать с файлами;
Это полное отсутствие методов для взаимодействия с сетью.

Последний пункт расстроил меня больше всего. Мне очень понравились идеи легковесности и компилируемости, которые несёт в себе QJS, но серверный JS без самого сервера — штука довольно-таки бесполезная.

Исходные коды QJS доступны на гитхабе всем желающим. Я решил взглянуть на них и понял, что даже несмотря на то, что на C я никогда всерьёз не писал, понять, что там происходит, оказалось не так сложно. И именно тогда во мне зародилась идея добавить в этот движок чуть-чуть сервера.

А как работать-то будет

QuickJS предполагает следующий процесс:

Сам функционал какого-либо модуля пишется на C;
На C же пишется “прослойка”, использующая QJS-api, которая говорит интерпретатору или компилятору, что вот тут-то мы и вызываем C-функции;
Внутри JS-скриптов мы импортируем JS-переменные из скомпилированной shared-библиотеки.

В итоге мы получаем простое решение: если мы хотим добавить что-то в QJS, нужно найти или написать новый функционал на C, а затем просто написать API-прослойку.

Если честно, в этой работе я не сделал ничего особо важного. Я нашёл сервер на C, который показался мне идеально подходящим для моей задумки — библиотеку httpserver.h. Взяв его за основу, я написал немного связующего кода, и получился QuickWebServer — динамическая библиотека, привносящая в QJS функционал веб-сервера с Express-подобным API. Давайте же посмотрим, как оно работает!

Первый сервер на QJS

Прежде всего, рекомендую вам скачать, собрать и установить QuickJS. Лишним точно не будет. Скачать можно из этого репозитория. Далее, для пользователей Mac и Linux проблем никаких - сперва запускаете make и ждёте, пока проект соберётся, а затем make install, чтобы все файлы поместились в нужные папки. Для пользователей Windows тоже можно собрать, но я, к сожалению, не проверял.

Также давайте убедимся, что у вас установлен Node.js и NPM. Это выглядит нелогичным, ведь мы не будем использовать Node, но установка пакетов удобнее с помощью NPM.

Давайте создадим тестовый проект, к примеру, в папке first-server.

# ~/first-server
npm init -y

Теперь нам нужно скачать и собрать QuickWebServer (далее - QWS). Он опубликован в NPM:

npm i -S @lyohaplotinka/quickwebserver

Появилась папка node_modules, а также началась сборка shared-библиотеки. Это может занять определённое время, так что можем отвлечься.

Пока что начнём писать код нашего сервера. Первым делом импортируем библиотеку:

import QuickWebServer from './node_modules/@lyohaplotinka/quickwebserver/src/QuickWebServer.js';

Важное замечание: QuickJS не Node.js, поэтому он:

Не ищет модули автоматически в node_modules;
не умеет загружать index.js из папки;
требует всегда указывать расширение файла после точки.

Двигаемся дальше. Создадим экземпляр:

import QuickWebServer from './node_modules/@lyohaplotinka/quickwebserver/src/QuickWebServer.js';

const server = new QuickWebServer();

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

import QuickWebServer from './node_modules/@lyohaplotinka/quickwebserver/src/QuickWebServer.js';

const server = new QuickWebServer();

server.get('/', async (request, response) => {
  response.type('text/html');
  response.send('Hello from QuickJS!');
});

Осталось лишь начать слушать соединения:

import QuickWebServer from './node_modules/@lyohaplotinka/quickwebserver/src/QuickWebServer.js';

const server = new QuickWebServer();

server.get('/', async (request, response) => {
  response.type('text/html');
  response.send('Hello from QuickJS!');
});

server.listen(3000);

Код выше - минимальный пример работы. О, кажется, у нас завершилась сборка. Запустим!

# ~/first-server
qjs ./server.js

Открываем в браузере http://localhost:3000 и видим:

Hello from QuickJS!

В целом, уже победа: у нас сервер на JS, но не Node.js. Круто!

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

Компилируем сервер

Сейчас QWS не часть QuickJS, а динамическая библиотека. Чтобы не таскать её за собой, нам нужно собрать программу со статической линковкой. Признаюсь честно, мне эта операция показалась не самым лёгким занятием, поэтому я решил это дело немного автоматизировать.

В составе пакета quickwebserver распространяется скрипт create-build-makefile.sh. Он, собственно, создаёт Makefile, в котором прописаны все необходимые шаги для сборки. Вызовем его так:

# ~/first-server
./node_modules/@lyohaplotinka/quickwebserver/create-build-makefile.sh ~/first-server/server.js

Как видите единственный аргумент - абсолютный путь к главному файлу нашего приложения. После выполнения команды рядом с файлом server.js появится Makefile.

Остался один шаг до сборки. Откроем server.js и поправим импорт QWS так, чтобы подключалась версия для статической сборки:

import QuickWebServer from './node_modules/@lyohaplotinka/quickwebserver/src/QuickWebServer.build.js';

Время выполнить самый простой шаг - просто вызвать команду make. Совсем скоро рядом появится исполняемый файл server. Если его запустить и перейти на http://localhost:3000, мы увидим всё ту же приятную фразу:

Hello from QuickJS!

Отдельно радует размер исполняемого файла - чуть больше мегабайта. Кстати, при компиляции из QuickJS можно “выпилить” какие-либо фичи языка, если они не используются. Так вы сократите размер файла.

Очень важно, что это никакой не “хак”, типо упаковки рантайма и кода в один пакет чисто “для виду”. При желании вы можете использовать QuickJS не для компиляции в бинарник, а для превращения вашего кода в C.

А зачем это вообще нужно?

Это извечный вопрос. Однако, у меня есть пара ответов.

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

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

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

В-четвертых, мне уже давно хотелось бы иметь какую-нибудь маленькую альтернативу Node.js, созданную для каких-нибудь простецких целей. Поэтому я лично рад, что у меня получилось это реализовать вот так.

Резюме

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

Во всём Интернете сейчас всего лишь один сайт работает на QWS - и это сайт его документации (https://qws.lyoha.info). Он, кстати, загружает доки из маркдауна и рендерит их на стороне JS. Уже что-то!

Тем не менее, эта работа меня сильно вдохновила. Поэтому я завёл на гитхабе организацию QuickJS Web Project, в которой хочу попытаться привнести в QJS всё то, что нужно для работы хорошего серверного движка. Если вы чувствуете силы и желание - я буду только рад работать вместе :)

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

Деплой JavaScript-приложений

2021-07-22T09:58:00.012Z

Почему это важно?

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

Всегда есть варианты и свобода выбора, и деплой не исключение. Само слово deployment означает “развёртывание, размещение”, что, в целом, отражает конечную цель этого процесса.

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

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

Стадия 1: “Зачем мне что-то? Хостер уже дал мне FTP!”

Итак, за окном 2015 год, и я только начинаю осваивать искусство вебдева. Мой сайт – PHP/jQuery/CSS, никаких сборщиков, гита и прочего, просто файлы, которые достаточно положить в правильную директорию на сервере. Чем я, собственно, и занимаюсь.

Сейчас уже трудно вспомнить, каким хостинг-провайдером я пользовался, но это было что-то в стиле “заплати 5 рублей и получи соответствующую услугу”, но я, как человек, у которого нет денег и есть самый первый заказ по фрилансу, счастлив этому безмерно.

Первый вариант – самый простой – доступ к серверу по FTP и ручная загрузка файлов.

Это может быть хорошо, потому что:

Не требуется абсолютно ничего, кроме FileZilla или аналогов;
Сэкономит вам время, если сайт статический, и кодовая база в обозримом будущем не будет обновляться;
Есть на подавляющем большинстве платных и бесплатных хостингов.

Однако, эта статья называется не “Деплой статических сайтов”, так что вы вполне законно можете спросить: при чём тут статика? И будете правы. Плох данный способ тем, что он лишает вас очень много полезных штук:

Версионирования релизов;
Возможности быстро “откатить” релиз, если в нём ошибка;
В случае использования сборщиков (Webpack и т.д.), помечающих собранные файлы хэшем, этот способ приведёт к файловой путанице.

Естественно, есть и самый очевидный минус – это неудобно, долго, да ещё и руками надо что-то делать. Мне, как чертовски ленивому человеку, это не подходит. Едем дальше!

Стадия 2: “Окей, я буду как большие дяденьки! Где мой Git?..”

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

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

В голове у меня сидела мысль: если Git - система контроля версий, то кому, как ни ей, заниматься контролем версий на продакшне? Таким образом процесс деплоя представляет собой клонирование репозитория в нужную папку и периодические git pull.

Плюсы такого способа:

Вы всегда знаете, что на продакшне тот же код, что и на вашем компьютере
Решение более-менее автоматизированное: достаточно лишь вызвать команду.

Однако, есть и минусы, и довольно серьёзные. Прежде всего, давайте признаем: как бы мы с вами ни отыгрывали знатоков, рано или поздно возникает момент, когда ты правишь что-то прямо на продакшне, к примеру, какую-нибудь критическую ошибку. Это вынуждает нас внимательно следить за состоянием кода в репозитории и на бою, убеждаться в том, что нет конфликтов, делать пуши в мастер прямо с продакшна, или делать пулл-реквесты. Кроме того, минусы такие:

Конфликты могут сломать ВСЁ. Поверьте, я знаю, о чём говорю. Если случается конфликт при обновлении кодовой базы, Git пометит мх прямо в файлах, ломая синтаксис. Если познания Git не очень большие, быстро устранить проблему может быть сложно.
Если доступ к серверу имеют несколько человек с разными логинами и правами, нужно обладать неплохими познаниями Linux, чтобы все они могли выполнять git pull
Раз уж речь про JavaScript, то нужно сказать, что этот способ вынуждает нас хранить собранные файлы в репозитории. А это как-то не круто. Тем более, если проект серверный: нужно либо дёргать npm install после обновления, либо хранить в репозитории папку node_modules. Чувствуете мурашки на коже?

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

Мой вердикт: это тоже не подходит.

Стадия 3: Shipit, потому что каждый инструмент должен делать своё дело

Через какое-то время я увидел инструмент PHP Deployer, который сразу мне понравился. Я начал поиски аналога для JavaScript, и вскоре нашёл Shipit. По заверению их репозитория, это универсальный инструмент для автоматизации и деплоя.

Вкратце, Shipit делает следующее:

Создаёт на вашем компьютере временную папку, куда клонирует ваш репозиторий для получения актуальной кодовой базы
Даёт возможность делать с этими файлами что угодно, к примеру, устанавливать зависимости и запускать сборку
Подключается к вашему серверу по SSH и загружает файлы в удалённую папку

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

Начать использовать его очень просто. Проверьте, вы соблюли эти условия:

У вас есть доступ к Git-репозиторию
У вас есть SSH-доступ к продакшн серверу

Далее, вам нужно установить два пакета:

npm install --save-dev shipit-cli
npm install --save-dev shipit-deploy

Первый пакет - инструменты командной строки, второй - набор тасков (от оригинального “tasks”), которые предназначены для деплоя.

Далее, в корне вашего проекта нужно создать конфиг-файл shipitfile.js. В репозитории проекта есть пример этого файла, но я покажу вам конфигурацию, которая мне показалось наиболее удачной и которой я сам пользуюсь.

I. Деплой компилируемого фронтенда

Это может быть приложение на каком-нибудь фреймворке или библиотеке, в моём случае - на Vue.js. Будем рассматривать конфиг-файл на примере выдуманного проекта MyFrontend

// shipitfile.js
const path = require('path')
const WORKSPACE_DIR = '/tmp/myfrontend'

Нам понадобится path из стандартной библиотеки Node. Переменная WORKSPACE_DIR – это временная папка, в которую Shipit будет клонировать репозиторий и производить манипуляции с ним.

// shipitfile.js
const path = require('path')
const WORKSPACE_DIR = '/tmp/myfrontend'

module.exports = (shipit) => {
    require ('shipit-deploy').(shipit)
    
    shipit.initConfig({
        default: {
            workspace: WORKSPACE_DIR,
            dirToCopy: path.join(WORKSPACE_DIR, 'dist'),
            deployTo: '/var/www/myapp/myfrontend',
            repositoryUrl: 'https://gitgit.git/myapp/myfrontend.git',
            ignores: ['.git', 'node_modules'],
            keepReleases: 5,
            keepWorkspace: false,
            shallowClone: false,
            deploy: {
                remoteCopy: {
                    copyAsDir: false
                }
            }   
        },
        staging: {
            servers: 'myuser@123.45.678.90'
        }
    })
}

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

workspace – передаем путь до локальной папки
dirToCopy – какую папку из склонированного репозитория мы будем загружать. Если не прописать этот ключ, Shipit загрузит всю папку workspace
deployTo – куда на удалённом сервере нужно положить наши файлы из предыдущей папки
repositoryUrl – адрес вашего Git-репозитория
ignores – какие файлы и папки точно не нужно загружать. Вообще, указание dirToCopy решает эту проблему, но лучше перестраховаться, как мне кажется.
keepReleases - сколько релизов будет храниться на продакш сервере, и, соответственно, на сколько релизов назад вы сможете откатиться
copyAsDir – как копировать папку dirToCopy на сервер: создавать на сервере эту же папку (true) или же просто загрузить её содержимое в deployTo (false)
staging – это всего лишь название конфигурации деплоя, оно может быть любым
servers - один или несколько IP-адресов сервера с указанием имени пользователя.

Если мы прямо сейчас запустим процесс деплоя, мы вряд ли добьёмся успеха: склонированный из Git проект не собран, а папка dist не существует. Значит, нам нужно “вклиниться” в процесс деплоя и вовремя собрать наш проект. В этом нам помогут уже упомянутые мной события.

Добавим в наш файл следующее:

// shipitfile.js
const path = require('path')
const WORKSPACE_DIR = '/tmp/myfrontend'

module.exports = (shipit) => {
    require ('shipit-deploy').(shipit)
    
    shipit.initConfig({
        default: {
            workspace: WORKSPACE_DIR,
            dirToCopy: path.join(WORKSPACE_DIR, 'dist'),
            deployTo: '/var/www/myapp/myfrontend',
            repositoryUrl: 'https://gitgit.git/myapp/myfrontend.git',
            ignores: ['.git', 'node_modules'],
            keepReleases: 5,
            keepWorkspace: false,
            shallowClone: false,
            deploy: {
                remoteCopy: {
                    copyAsDir: false
                }
            }   
        },
        staging: {
            servers: 'myuser@123.45.678.90'
        }
    })

    shipit.on('fetched', async () => {
        await shipit.start('app:build')
    })
    
    shipit.blTask('app:build', async () => {
        await shipit.local(
          `cd ${WORKSPACE_DIR} && npm install && npm run build`
        )
    })
}

У пакета shipit-deploy есть набор событий на каждое действие (ознакомиться можно тут). Нам интересно событие fetched, которое происходит сразу после клонирования репозитория. В нём вызываем наш собственный таск app:build.

app:build объявлен как blTask: в Shipit это значит, что задача блокирующая, и начинать следующую задачу нельзя, пока не завершится эта. В ней мы при помощи метода shipit.local запускам локальную команду: переходим в WORKSPACE_DIR, устанавливаем зависимости и собираем проект.

Если в процессе сборки что-то пойдёт не так, деплой прекратится: “сломанный” код не окажется на продакшне.

Всё готово к деплою: в командной строке набираем ./node_modules/.bin/shipit staging deploy. Когда процесс завершится, в папке на сервере вы увидите два элемента: директорию releases и симлинк current. Ваш веб-сервер нужно направить именно на симлинк, чтобы в браузер отдавались только актуальные файлы.

Если что-то всё же пошло не так, и нужно срочно вернуть предыдущий релиз, вы можете вызвать команду ./node_modules/.bin/shipit staging rollback. Она переключит симлинк current на предыдущий релиз.

II. Деплой бэкенда на Node.js

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

// shipitfile.js
const path = require('path')
const WORKSPACE_DIR = '/tmp/mybackend'

module.exports = (shipit) => {
    require ('shipit-deploy').(shipit)
    
    shipit.initConfig({
        default: {
            workspace: WORKSPACE_DIR,
            deployTo: '/var/www/myapp/mybackend',
            repositoryUrl: 'https://gitgit.git/myapp/mybackend.git',
            ignores: ['.git', 'node_modules'],
            keepReleases: 5,
            keepWorkspace: false,
            shallowClone: false,
            deploy: {
                remoteCopy: {
                    copyAsDir: false
                }
            }   
        },
        staging: {
            servers: 'myuser@123.45.678.90'
        }
    })

    shipit.on('updated', async () => {
        await shipit.start('app:install-deps')
    })
    
    shipit.blTask('app:install-deps', async () => {
        await shipit.remote(
            `cd ${shipit.releasePath} && npm install`
        ) 
    })
}

Ключевые изменения:

Убрали dirToCopy, так как обычно бэкенд-проекты начинаются от корня репозитория
Теперь мы завязываемся на событие updated, которые происходит после создания новой папки внутри releases на сервере и копирования файлов туда.
В блокирующей задаче app:install-deps мы при помощи shipit.remote запускаем установку зависимостей на сервере, перемещаясь в папку релиза. Заранее мы не знаем, какую папку создаст Shipit, но её можно легко получить на этом этапе при помощи shipit.releasePath

Также может понадобиться перезапустить приложение Node. Для этого можно использовать событие deployed, и вызвать, к примеру, pm2 reload, если для запуска ноды в бою вы используете PM2.

IV. Деплой компилируемого бэкенда на Node.js

Да-да, я говорю про TypeScript. Однако, я думаю, что сложив вышеописанные шаги, вы получите как раз то, что вам нужно :)

Итоги

Хороший деплой – это, прежде всего, сэкономленные нервы. Вы знаете, что можете быстро развернуть новую версию, или вернуть предыдущую, если что-то пошло не так. Вы знаете, что у вас никогда не возникнет путаницы на продакшне, и вы всегда будете видеть, сколько релизов было сделано.

Расширив shipitfile.js, вы можете логировать деплои, собирать статистику, да и вообще делать всё, что вам нужно. Потратив на настройку минут 20 один раз, вы сохраните кучу времени в будущем.

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

Страшная реактивность

2021-07-22T09:53:52.358Z

Череда страхов

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

Так было с Node.js, с Typescript, с React и многим-многим другим. Та же участь постигла и реактивность. До относительно недавнего времени нутро фронтентд-библиотек казалось мне какой-то магией высшего порядка.

К сожалению, интернет помогает далеко не всегда. Очень часто я сталкивался с тем, что статьи “для начинающих” предполагают, что у тебя уже есть довольно серьёзный бэкграунд по теме. К примеру, я читал много статей про Node.js для начинающих, но до меня далеко не сразу дошло, что это про сервер. Конечно, это рождает много вопросов к моему интеллекту, но, всё же, я был довольно “зелёный”.

Реактивность

Уверен, все заметили, что это слово очень часто мелькает в материалах по фронтенду. В принципе, до определённой точки знать что это такое и как именно это работает необязательно, но рано или поздно настанет момент, когда станет либо слишком интересно, либо натурально необходимо.

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

Реактивность - не от слова “реактивный”, как самолёт
Да, звучит глупо, но я правда так думал, и предполагаю, что я такой не один. Многое сразу становится понятно, когда осознаёшь, что это слово образовано от слова “реакция”. Впрочем, “реактивный” в контексте самолёта тоже произошло от слова “реакция”, но в обиходе оно вызывает ассоциации с чем-то быстрым, технологичным и т.д.
Вы используете реактивность, если работаете с JavaScript даже без фреймворков и библиотек
В общем смысле реактивность реализует идею “событие - реакция”. Каждый из нас работал с этим, вне всяких сомнений. К примеру, если вы писали обработчик нажатия на кнопку - в каком-то смысле это реактивность :)
Реактивность - это не rocket science, это обычный код
И чаще всего довольно простой. Позволю себе небольшой спойлер: совсем скоро в этой публикации мы рассмотрим пример реактивного кода, и он займет менее 30 строк кода.
Спектр задач, который можно решить с помощью реактивного кода, шире, чем фронтенд-библиотеки Всё ограничено вашей фантазией. Если вам кажется, что на бэкенде можно решить что-то с помощью реактивности - не бойтесь это делать.

От слов к делу

Давайте рассмотрим простейший пример работы с DOM. Допустим, вам нужно получить внутренний html элемента после того, как браузер построил дерево элементов. Предположим, что мы пишем код внутри head.

В вашем коде вы, скорее всего, напишете так:

const elem = document.getElementById('myelem');
const html = elem.innerHTML

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

Да и зачем, если есть событие DOMContentLoaded, которое как раз сигнализирует, что DOM построен? Мы лучше сделаем так:

document.addEventListener('DOMContentLoaded', function() {
  const elem = document.getElementById('myelem');
  const html = elem.innerHTML
})

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

Сделай определённое действие, когда узнаёшь, что произошло определённое событие

Используем встроенные возможности

Все браузеры реализовали спецификацию событий в том или ином виде. Есть два основных способа отправить событие: через Event и CustomEvent (если вам это не знакомо, почитайте здесь).

Использование метода dispatchEvent, а также прикрепление обработчика через addEventListener как раз реализует принцип “событие - реакция”.

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

function calculate(...args) {
/* 
    ...
    Тут проводим вычисления, и в конечном итоге
    получаем переменную result
  */
  if (result > 200) {
    const event = new Event('moreThan200')
    window.dispatchEvent(event)
  }
}
// А тут как раз добавляем обработчик
window.addEventListener('moreThan200', function() {
  alert('Результат больше 200!')
})

Код выше “реагирует” на определённые условия, запуская функцию-обработчик. Реакция может быть любой, а можно и данные передать (используя detail) в CustomEvent. Чётко! Удобно!

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

Паттерн Observable

Есть шаблон проектирования, который называется “Observable” (наблюдаемый). С виду он позволяет делать практически то же самое, что и браузерные события. Разница лишь в том, что раз мы реализуем его самостоятельно, он может быть оптимизирован под конкретные задачи.

Главная задача Observable – уведомлять всех, кто наблюдает за его состоянием (они же называются Observer) о том, что оно поменялось. На языке умных и взрослых дяденек это называется связью “один ко многим”. Единственная задача наблюдаемого объекта – сообщить об изменениях и, возможно, передать изменённые данные. Что с этими данными делают наблюдатели ему, по задумке, не интересно.

Очень многие реактивные библиотеки имеют в основе этот паттерн. К примеру, writable в Svelte – реализация Observable, как и Rx.js. Интересно ещё и то, что этот паттерн можно реализовать практически в любом языке программирования (смотрите тут, лично я отдельно умилился с Pascal).

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

Итак, мы будем работать с синтаксисом JavaScript-классов, потому что он мне нравится, однако, этого же можно добиться и через Object.defineProperty.

Наш собственный Observable

class Observable {
    constructor(initialValue = null) {
        this._value = initialValue
    }
}

Начнётся всё так. В конструктор нашего класса мы должны передать изначальное значение. Если мы его не передаём, мы считаем, что оно равно null. Значок “земля” добавляем для того, чтобы впоследствии задать для объекта геттер и сеттер по ключу value.

Кстати: лично я больше люблю TypeScript, и в плане изначальных значений там может быть больше вариантов. К примеру, лучше использовать дженерики, чтобы понимать, с каким типом данных работает наблюдаемый объект.

У Observable должно быть ещё одно свойство – “очередь” наблюдателей. Если называть вещи простыми словами, то очередь - обычный массив или объект, в который мы будем “складывать” новых подписчиков. Я предпочитаю объекты, потому что люблю обращаться по ключам:

class Observable {
    constructor(initialValue = null) {
        this._value = initialValue
        // Добавляем очередь наблюдателей
        this.subscribersQueue = {}
    }
}

Самое время реализовать метод подписки на изменение значения. Алгоритм такой:

Добавить переданный метод в очередь, присвоив ему идентификатор;
вернуть функцию “отписки”, чтобы можно быть отвязаться от наблюдения за объектом.

class Observable {
    constructor(initialValue = null) {
        this._value = initialValue
        this.subscribersQueue = {}
    }

    // Метод subscribe - подписываемся на изменения
    subscribe(listener) {
        const listenerId = Math.random().toString(36).substr(2, 9)
        this.subscribersQueue[listenerId] = listener
        return () => delete this.subscribersQueue[listenerId]
    }
}

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

class Observable {
    constructor(initialValue = null) {
        this._value = initialValue
        this.subscribersQueue = {}
    }

    subscribe(listener) {
        const listenerId = Math.random().toString(36).substr(2, 9)
        this.subscribersQueue[listenerId] = listener
        return () => delete this.subscribersQueue[listenerId]
    }
    
    // Геттер: получаем значение
    get value() {
        return this._value
    }
    
    // Сеттер: обновляем значение и вызываем метод-уведомитель
    set value(newValue) {
        this._value = newValue
        this.notifySubscribers()
    }
    
    // Вспомогательный метод-уведомитель
    notifySubscribers() {
        for (const listenerId in this.subscribersQueue) {
            const listener = this.subscribersQueue[listenerId]
            listener(this._value)
        }
    }
}

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

Вернёмся к первому примеру из этой публикации: div-элемент с id myelem:

<div id="myelem">
    Text inside
</div>

Сейчас мы можем связать наблюдаемую переменную с контентом этого блока, и в автоматическом режиме менять свойство innerHTML. Для этого напишем функцию:

function observeHtml(id) {
  const elem = document.getElementById(id)
  if (!elem) return
  const value = elem.innerHTML
  const observable = new Observable(value)
  observable.subscribe((value) => {
    elem.innerHTML = value
  })
  return observable
}

Осталось только вызвать эту функцию с нужным ID:

const myElemObservable = observeHtml('myelem')

Теперь если мы напишем, скажем, myElemObservable.value = 'New content', содержимое блока div сразу изменится. А что будет, если мы пройдёмся по всем-всем-всем элементам в документе и создадим их “тень”, состоящую из Observable, сохраняя иерархию через JSON? Получится тот самый пресловутый Virtual Dom.

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

Реактивность как помощник

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

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

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

На данный момент я использую это в своих проектах, к примеру, в роутере Easyroute. Понимание принципов реактивности помогло решить много проблем в нём.

Как я и говорил, нет ничего сверхъестественного в реактивности. Все поначалу удивительные задачи решаются в несколько строк кода.

Асинхронные плагины для Vue.js

2021-07-22T09:46:39.000Z

Представим ситуацию. Вы делаете большое приложение на Vue.js: тут вам и отдельная команда бэкендеров, и вдумчивая разработка, и вообще всё, что полагается.

У приложения есть API, он версионный и часто меняющийся. Бэкендеры решают использовать для автоматизации спеки и визуализации методов какую-нибудь утилиту, допустим – Swagger. На стороне фронта вы используете модуль Swagger’a, чтобы при помощи спецификации обращаться к методам не по URL, так как в процессе разработки он часто, но незначительно меняется, а по имени метода, которое назначено вашим бэкендовым коллегой.

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

Круто, да?

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

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

Есть несколько решений:

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

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

Итак, перейдем же к реализации!

Реализация

Есть у JavaScript (как, впрочем, и у других языков) замечательная особенность: возвращать данные из функции. В частности – объекты. Кроме того, в JavaScript функция может быть асинхронной: этим мы и воспользуемся.

В данном примере я буду использовать синтаксис async-await, но того же эффекта можно добиться и промисами.

Итак, представим, что у нас есть проект на Vue, в папке src нам нужны три файла:

# ./src

main.js                # Главный файл приложения
AsyncService.js        # Файл с классом того самого плагина, 
                       # который выполняет асинхронное действие при инициализации
AsyncService.plugin.js # Файл, который будет импортироватсья в main.js

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

Давайте займемся написанием асинхронного плагина. Для этого откроем AsyncService.plugin.js и напишем туда следующее:

// ./AsyncService.plugin.js
import AsyncService from 'AsyncService'

const AsyncServicePlugin = {
    install: function (Vue) {
      Vue.prototype.$service = new AsyncService()
    }
}

export default AsyncServicePlugin

Примерно так выглядит обычный плагин Vue в общем смысле: в прототип добавляется что-либо, что пригодится в будущем.

Теперь представим, что у нашего сервиса есть некий метод asyncInit, который выполняет, как не трудно догадаться, асинхронную инициализацию. Если мы вызовем его в методе install, то поток программы не будет дожидаться его выполнения, даже если мы объявим install как асинхронный. Решение – обернуть все это в асинхронную функцию, и возвращать уже готовый экземпляр AsyncService:

// ./AsyncService.plugin.js
import AsyncService from 'AsyncService'

const initAsyncServicePlugin = async () => {
    const asyncService = new AsyncService()
    await asyncService.asyncInit()
    return {
        install: function (Vue) {
          Vue.prototype.$service = asyncService
        }
    }
}

export default initAsyncServicePlugin

Мы экспортировали уже не сам объект плагина, а функцию, которая его возвращает.

Как же теперь использовать его с Vue.use? На помощь приходят так называемые IIFE, или немедленно вызываемые функциональные выражения. И да – они могут быть асинхронными!

Все, что нужно сделать – обернуть создание экземпляра Vue в такое выражение, предварительно добавив подключение нашего плагина:

// ./main.js
import AsyncServicePlugin from './AsyncService.plugin'
...

(async () => {
    Vue.use(await AsyncServicePlugin())
    new Vue({
     ...
    })
})()

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

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

Так решил эту проблему я, однако я буду рад узнать другие решения :)

Vue CLI: меняем индекс-файл при сборке

2021-07-22T09:42:39.452Z

Те, кто уже работал с Vue.js при помощи Vue CLI, знают, что эта надстройка над вебпаком берёт очень многие вещи на себя, упрощая процесс сборки проекта и развития его экосистемы.

Можно, к примеру, добавить плагин для PWA и без лишних телодвижений превратить своё приложение в PWA. Также Vue CLI контролирует сборку приложения, создавая файловую структуру и заполняя файл index.html

Поворотный момент

Буквально неделю назад передо мной встала задача в результате сборки проекта при помощи Vue CLI получать не html-файл, а php, в котором реализуется некая серверная логика.

Поверхностное гугление показало, что можно использовать webpack-php-loader для сборки проекта. Однако это не решало мою проблему: насколько я понял, этот лоадер запускает php на машине, на которой происходит сборка, рендерит его и на выходе всё равно выдаёт html. Мне это не подходило, так как в php я работал с юзерагентом, передаваемым конкретным пользователем.

Решение - vue.config.js

В итоге мне удалось найти инструкцию, как указать файл, который при сборке будет считаться за “шаблон”, а также как переименовать выходной файл после сборки проекта. Делается это в файле vue.config.js.

Давайте определим себе задачу: закрыть доступ пользователям Internet Explorer 9.

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

Если у вас ещё нет этого файла, создайте его в корне вашего проекта (на одном уровне с package.json) и поместите туда экспортный объект в синтаксисе Node.js:

// ./vue.config.js
module.exports = {

}

Далее, в папке src вашего проекта, создайте файл-шаблон, который будет использоваться при сборке. ВАЖНО: не удаляйте оригинальный файл index.html из папки public! Он нужен нам, чтобы работать в development-режиме и сохранить всякие прелести вроде хот-релоад.

Допустим, он называется index_template.php Скопируйте в него содержимое файла ./public/index.html, добавив где нужно логику на php.

// ./src/index_template.php
<?php
  $isIE9 = strpos($_SERVER['HTTP_USER_AGENT'], 'MSIE 9.') !== false;

  if ($isIE9) {
    die('Браузер не поддердживается!');
  }
?>

<!DOCTYPE html>
<html lang="ru">
  <head>
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta charset="utf-8">
    <meta name="viewport" content="width=device-width,initial-scale=1.0">
    <link rel="icon" href="<%= BASE_URL %>favicon.png">
    <title>Site title</title>
  </head>
  <body>
    <noscript>
      <strong>We're sorry but website doesn't work properly without JavaScript enabled. Please enable it to continue.</strong>
    </noscript>
    <div id="app"></div>
    <!-- built files will be auto injected -->
  </body>
</html>

Здесь мы просто для примера определяем, точно ли IE9 перед нами, и если да, прекращаем выполнение скрипта.

Осталось прописать настройки в vue.config.js

Первым делом сообщим, что после наполнения файла содержимым сохранять его нужно не как index.html, а как index.php:

// ./vue.config.js
module.exports = {
    indexPath: 'index.php'
}

Эта настройка создаст в папке dist файл с нужным расширением.

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

// ./vue.config.js
module.exports ={
    indexPath: 'index.php',
    // Добавляем это:
        chainWebpack: config => {
        if (process.env.NODE_ENV === 'production') {
          config
            .plugin('html')
            .tap(args => {
              args[0].template = './src/index_template.php'
              args[0].minify.removeAttributeQuotes = false
              return args
            })
        }
    }
}

Здесь мы обращаемся к html-загрузчику вебпака, и сообщаем, что при сборке в production шаблон теперь находится по адресу ./src/index_template.php. Также мы говорим, что при минификации кода не нужно удалять кавычки атрибутов, так как иногда это может нарушить работу php-скрипта.

На этом всё! Попробуйте запустить npm run build и вы увидите в папке dist файл index.php, полностью готовый к работе на продакшн-сервере!

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

Если у вас есть другое решение этого вопроса - я буду только рад с ним ознакомиться.

Организация работы с Vue: к чему я пришёл

2021-07-22T09:37:40.770Z

Моя первая публикация в блоге…

…и сразу же про Vue.js. На самом деле, меня довольно многое связывает с этим фреймворком. Моё первое SPA-приложение было написано на jQuery: использовало AJAX для загрузки уже отрендеренного HTML и замены его в определённом блоке, который сейчас бы я назвал router-outlet.

Vue.js стал первым фреймворком в моей жизни и сразу показал мне, что SPA - это не больно. Круто было осознавать, что больше не нужно изобретать кучу велосипедов, чтобы “сайт менял страницы не перезагружаясь”.

В течение двух лет я пишу на Vue, и выработал несколько практик, которые с каждым днём делают мою работу легче. Прежде всего это касается организации работы с данными.
Я жалею только об одном: что не додумался об этом раньше.

Небольшой дисклеймер: я не претендую на первенство. Скорее всего, так до меня уже кто-то делал. Я всего лишь делюсь своими соображениями.

Что предполагает Vue

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

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

Если проблему с хранением данных решает Vuex, то от избытка кода никуда не уйти. И хотя Webpack успешно решает вынос javascript-части приложения в отдельный файл через script src, размер этого файла легко может выйти из-под контроля.

Можно перенести часть логики во Vuex, но это также может оказаться не самой лучшей идеей. Во-первых потому, что рано или поздно хранилище разрастётся (даже если выносить всё в отдельные модули), а во-вторых потому, что (и это моё субъективное мнение) работа с Vuex довольна громоздкая в плане написания кода (this.$store.commit( ‘NameOfMutation’, payload )).

В итоге, спустя два года активного написания приложений на Vue, я пришёл к простой истине: разделение - это хорошо.

Разделение - это хорошо

Мой подход заключается в простой вещи: мы должны поделить приложение на “зоны ответственности”:

Шаблон. Файл с расширением .vue, который нужен исключительно для отрисовки данных. В нём не должно происходить ничего, кроме того, что нужно для отрисовки данных. Исключение составляют методы и computed-свойства, отвечающие за финальную подготовку данных к показу в шаблоне.
Стили. Если компонент или страница имеют большое количество стилей, то их лучше вынести в отдельный css-файл (или файл других стилевых движков). Для себя я определил порог в 100 строк. Если стилей больше, они переезжают в свой файл.
Логика. Я предпочитаю выносить всю работу с логикой компонента в отдельный сервис. Благо, новые стандарты javascript уже имеют синтаксический сахар для классов, поэтому я использую именно их. Если ваш проект пишется на typescript, то использовать сервисы-классы становится ещё на порядок приятнее.
Данные. Здесь нам приходит на помощь Vuex и его именованные пространства имён. Важно, что в vuex-хранилище я не провожу никакие операции с данными, несмотря на наличие actions. Сторы я использую только для хранения, а все операции производятся в сервисе.

На практике

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

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

Итак, представим, что мы находимся в папке src приложения. В ней я создаю директорию components/FilmSearcher. Создадим в ней следующие файлы:

# ./src/components/FilmSearcher/

./FilmSearcher.vue
./FilmSearcher.service.js
./FilmSearcher.store.js
./FilmSearcher.style.scss

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

Файл шаблона будет выглядеть примерно так:

<template>
  <div class="film-searcher-component">
    <input 
      class="film-searcher-input" 
      type="text" 
      @input="searchFilms" 
      v-model="filmSearcherText"
    >
    <div class="film-searcher-autocomplete" v-if="filmVariants.length">
      <template v-for="(variant, idx) in filmVariants">
        <div class="film-searcher-variant" :key="idx" v-html="variant.title"></div>
      </template>
    </div>
  </div>
</template>

<script>
import FilmSearcherService from './FilmSearcher.service';

export default {
  name: 'FilmSearcher',
  data() {
    return {
      service: null,
      filmSearcherText: ''
    } 
  },
  computed: {
    filmVariants () {
      return this.service.filmVariants;
    }
  },
  methods: {
    async searchFilms () {
      await this.service.search(this.filmSearcherText);
    }
  },
  created () {
    this.service = new FilmSearcherService({
      store: this.$store
    });
  },
  beforeDestroy () {
    // Удаляем хранилище компонента
    this.service.unregisterStorage()
  }
}
</script>

<style lang="scss">
@import "./FilmSearcher.style";
</style>

В хуке created важно инициализировать наш сервис. Ещё важнее передать в него ссылку на глобальное хранилище приложения.

Пример файла-сервиса:

import http from 'http';
import FilmSearcherModule from './FilmSearcher.store' // Импортируем стор

export default class FilmSearcherService {
    constructor(payload) {
        this.payload = payload;
        this.registerStorage(); // Вызов создания хранилища
    }

    // Динамически создаём хранилище для нашего компонента
    registerStorage () {
        this.payload.store.registerModule('filmSearcher', FilmSearcherModule);
    }   
    
    // Удаляем хранилище компонента
    unregisterStorage () {
        this.payload.store.unregisterModule('filmSearcher');
    }   
    
    async search (filmTitle) {
        const foundVariants = await this.http.get('https://server.com', {title: filmTitle});
        const result = // ...здесь обрабатываем результаты, если нужно
        // Записываем обработанные данные в хранилище
        this.payload.store.commit('filmSearcher/setFilms', result);
    }

    get filmVariants () {
        return this.payload.store.getters['filmSearcher/films'];
    }

}

Мы видим, что в сервисе происходят все операции, которые нужны для получения данных. Главный метод сервиса – search – возвращает результат, который передаётся в компонент. Задача сервиса – максимально подготовить данные к как можно более быстрой отрисовке.

Также здесь мы используем возможность динамической регистрации модулей Vuex. Вы можете использовать и глобальный модуль, если это нужно.

Вот так выглядит vuex-модуль компонента

export default FilmSearcherModule {
    namespaced: true,
    state: {
        _films: []
    },
    mutations: {
        setFilms(state, payload) {
            state._films = payload;
        } 
    },
    getters: {
        films: (state) => state.films;
    }
}

Здесь наглядно видно, что vuex-модуль не используется для обработки данных. Только хранение, запись и чтение. Всё.

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

Проговорим вслух

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

При создании компонента вызывается конструктор его сервиса. В нём же мы автоматически инициализируем хранилище компонента.
Вся работа с данными в компоненте никогда не происходит напрямую. Компонент отдаёт приказ сервису, который уже залезает в хранилище, обрабатывает всё должным образом и отдаёт своему “начальнику”.
Сервис не только забирает данные из хранилища, но и добавляет их туда, обращаясь к мутациям.
Все операции с данными внутри хранилища происходят исключительно посредством мутаций и геттеров.
При запуске ивента beforeDestroy внутри компонента хранилище компонента автоматически удаляется.

А не лишнее?

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

Поначалу применение такого подхода немного увеличивает время, потраченное на начальном этапе разработки, но это время с лихвой компенсируется впоследствии, когда вы возвращаетесь с новыми задачами в старый компонент. Все преимущества разделения становятся прозрачнее при разработке больших проектов (особенно если в разработке используется TypeScript с class-based синтаксисом).

Итого

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

Интересно мнение сообщества на этот счёт!