Главная » Статьи » 5 вещей, которые я выучил, создавая Sass приложение с Vue.js

5 вещей, которые я выучил, создавая Sass приложение с Vue.js

5 вещей, которые я выучил, создавая Sass приложение с Vue.js

От автора: полгода назад я начал работу над своим первым «настоящим» Sass приложением Checkly. Этот пост – обзор 5 уроков, которые я выучил за последние полгода. Надеюсь, он поможет другим самоучкам-разработчикам, которые создают с Vue Sass приложения.

Чтобы вы поняли, опишу, что делает Checkly. Checkly – это инструмент для IT Ops и разработчиков. Он делает 2 вещи.

Активно проверяет корректность и время отклика конечных точек API.

Активно проверяет корректность критического потока кликов браузера.

Хватит нахваливать приложение, вот эти 5 уроков, которые я выучил.

1. Создать хорошую авторизацию сложно

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

В типичном нетривиальном сценарии много точек входа:

Регистрация

Авторизация через социальные сети

Имя пользователя/пароль логин

Сброс пароля

Колбек обработчик авторизации через соц. Сети

Обработчик регистрации

Это уже достаточно сложно, очень много чего должно сойтись, прежде чем пользователь сможет приступить к работе. Тестировать эти компоненты сложно – очень много back end’а и взаимодействия со сторонними сервисами. Со всем этим сложно работать. В своем решении я упростил подход и принял 2 определенных архитектурных решения:

Я буду использовать Auth0 для реальной аутентификации на back end. С помощью social login, username / password login и их сервиса JWT буду проводить аутентификацию пользователя в Checkly API. Дисклеймер: я никак не связан с Auth0, но их сервис очень хорош и дружит со стартапами, благодаря своему либеральному свободному плану.

Взаимодействие Abstract Auth0 в компонент сервиса в приложении Vue. Ваши компоненты Vue не знают о Auth0, токенах JWT. Они просто импортируют сервис auth и вызывают пару методов. В будущем легко заменить.

Необходимо отделить все «шаги» в свой роут и компонент. Так вы себе и другим упростите жизнь. Теперь с легкостью можно бросаться ссылками /login и /signup в маркетинге, не думая о состоянии компонента. Состояние определяется роутом, как на любой «нормальной» веб-странице.

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

Бонус: обработка несанкционированных состояний

Когда JWT токен пользователя устаревает, back end API даст вам знать, вернув заголовок 401 Unauthorised. Вы захотите перенаправить пользователя на страницу авторизации или показать дружелюбное сообщение. С помощью Axios http-клиента и Vue это можно сделать в 5 строк кода.

Добавьте перехватчик в Axios в центральный сервис http.js. Пусть Axios пропускает ошибку на шину сообщений Vue.js.

Ждите сообщение в верхнем компоненте и обрабатывайте его. В моем случае я буду делать редирект на /login.

2. Повторное использование компонента необходимо планировать

Что такое компонент? Компонентом может быть кнопка. Но компонентом может быть и весь экран. Все приложение – это компонент! Получается, что нет четкой границы между «компонентами» и «не компонентами».

Конечно, я не один задавался этим вопросом. Dan Abramov в своей статье в контексте ReactJS подводит итог: разделяйте компоненты на контейнеры и то, на что смотрите (компоненты представления в статье Dan, представления в моей). Единственное отличие моего решения – представления всегда ссылаются над подроуты.

В примере ниже показан стандартный экран редактирования. В нашем случае это экран редактирования проверки API. Это контейнер, ведущий на /checks/>id</edit/api. Экран на вкладке locations & scheduling, который ведет на свой подроут /scheduling

Вкладка содержит выбор страны и компоненты планирования времени (красные). Эти компоненты также живут на трех других экранах: 2 в мастере создания и 1 на экране редактирования проверок браузера.

Все эти экраны отличаются и предоставляют разный контекст данных и визуальный контекст для всех компонентов (находимся мы в режиме edit или create). Другими словами, не только данные, вставленные в изменения компонента (через свойства), но и визуальное расположение на экране. Здесь поможет разделение на containers / views.

Containers – роуты верхнего уровня и почти всегда читаются из Vuex

Views – явные подроуты контейнера, не хранят состояние.

Both – может хранить голые компоненты.

3. Развертывание на CDN также необходимо планировать

Теперь нечто совершенно другое!

Back end Checkly лежит на Heroku, поэтому я хотел обслуживать приложение на Heroku. Чем меньше движущихся частей, тем лучше! Но все сложнее, чем думаете.

Необходимо синхронизировать деплой приложения и деплой API. Не практично.

Скомпилированные файлы нужно упаковать в развертываемом API. В большинстве случаев это отдельные (git) проекты. Теперь необходимо добавить stage, в котором артефакты из одного проекта вставлены в другой.

Я искал сторонние deployment/CI/CD сервисы и наткнулся на Netlify. В конце концов, я использовал скрипт NPM и знания, полученные из AWS.

Поднимите S3 bucket и установите пакет s3-deploy NPM. Добавьте 3 строки в секцию скриптов package.json.

Разверните все файлы на S3 bucket и установите заголовки кэширования и etags.

Разверните index.html без заголовков кэширования – эффективный способ устаревания кэша, когда выходит новая версия.

Свяжите предыдущие 2 пункта. Готово.

Этот набор скриптов толкает приложение Vue.js, запущенное с помощью Vue-CLI, в AWS S3 bucket. В моем случае я также выходил на S3 bucket с AWS Cloudfront в виде CDN. При начальной установке необходимо задать пару начальных настроек:

Добавьте robots.txt в конфиг веб-пакета. Нужно приручить этих ботов.

Уже говорил, но все же: позаботьтесь о правильных заголовках кэширования. Вам нужно, чтобы все обновления кода и файлов были сразу видны. То есть файл index.html нужно загружать БЕЗ кэша. Это основная хорошая практика.

Настройте AWS S3 и AWS Cloudfront на обработку одностраничного приложения. Об этом почти ничего не сказано в документации AWS.

Настройте bucket на хостинг

Настройте страницу ошибки на index.html

Создайте свои сообщения об ошибках на Cloudfront для сообщений 404 и 403.

4. Используйте сторонние плагины, но только когда…

Я в IT уже примерно 20 лет. У меня есть более страшные истории о первом пузыре в интернете. Но по мере изменения технологий рынка и мира одна вещь не меняется.

Разработать хорошее и полезное приложение очень сложно и долго

Все ДО СИХ ПОР недооценивают это: менеджеры, инженеры, заказчики, я. Поэтому моя причина, почему я использую сторонние решения, open source фреймворки, плагины и т.д. – это возможность меньше работать. Не интегрироваться с чем-то прикольным, не последним использовать Х или У. Не потому, что это использует facebook. Вроде бы очевидно, но много кто забывает это.

Меньше слов. Ниже представлены 3 Vue.js плагина, которые я могу порекомендовать. Я часто их использую. Что они делают, наверное, и так понятно. Они не идеальны, но помогут разгрузить вас.

Bootstrap Vue

Vue-i18n

vee-validate

5. Инструменты разработчика Vue.js сильно экономят время

Расширение для Chrome с инструментами разработчика Vue.js удивительно. Я использую его каждый день. Для меня это составная часть экосистемы Vue.jsm как Vuex и Vue Router. Почему же он так хорош:

Я обращаю внимание на UI и UX. Я могу провести много времени, чтобы:

Получить нужный цвет

Получить переход, который сглаживает анимацию

Получить микро анимацию, добавляющую контекст

Получить выделяющийся шрифт

То есть в случае ошибок или чего-то еще я хочу получить что-то красивое. Заставить все работать на front end довольно сложно.

Переключение состояний в true/false путем быстрого редактирования действительно, ДЕЙСТВИТЕЛЬНО помогает, когда переходы и т.д. зависят от сложных back end состояний и XHR сообщений.

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

Если не добавить свои кнопки отладки для переключения этих состояний, вы мало что сделаете. Инструменты разработчика Vue.js решают эту проблему. Спасибо, инструменты разработчика Vue.js.

Автор: Tim Nolet

Источник: https://hackernoon.com/

Редакция: Команда webformyself.