Какие решения вам придется принять при организации кода для удобства чтения и повторного использования при разработке интерфейсного приложения JavaScript?
Какой практический выбор необходимо сделать при сохранении гибкости в выборе пользовательского интерфейса в отношении интеграции внутренних и внешних API-интерфейсов, разделения компонентов, управления состоянием, тестирования…?
Они (почти) никогда вам этого не скажут.
Почти, потому что в Интернете действительно больше качественного контента по этим темам, чем вы можете найти, когда речь идет о внутренних эквивалентах. Кстати, последнему я посвятил аналогичную серию несколько месяцев назад, если вам интересно:
Но все же большая часть этого контента направлена на раскрытие механизмов и их применение в небольших приложениях, иногда даже только в прототипах.
Таким образом, моя цель здесь - решить общие проблемы реального мира и еще раз поделиться с вами своим опытом создания приложений для моей (французской) компании Iperiago.
Наш вариант использования: туристическое приложение, написанное на JavaScript под Vue.js и взаимодействующее с серверной частью REST API.
Я буду использовать фреймворк пользовательского интерфейса, а именно Quasar: помимо того, что Quasar очень, очень хорошо спроектирован, он позволит нам сосредоточиться здесь на проблемах общей картины. В этой серии рассказывается о передовых методах пользовательского интерфейса, не поймите меня неправильно, но она не предназначена для того, чтобы изобретать велосипед, когда дело касается деталей реализации (особенно CSS).
Если вы предпочитаете другую структуру пользовательского интерфейса, такую как Vuetify или Buefy, не волнуйтесь слишком сильно: большая часть того, что я хочу сказать, останется в силе.
Конечно, я, вероятно, сделаю несколько самоуверенных заявлений здесь и там, но на этот раз я снова постараюсь всегда приводить разумные аргументы в пользу сделанного выбора.
Эта серия нацелена на фронтенд-разработчиков с предварительным знанием некоторого JavaScript, некоторых Vue.js и некоторых шаблонов проектирования, потому что мы иногда будем сокращать, чтобы быстро перейти к сути. Новички должны понимать суть всего, поскольку это следует правилам здравого смысла.
Безусловно, эта серия не является полноценным учебным пособием: вам предстоит заполнить пробелы, но, надеюсь, вы попадете на правильный путь и вам будет над чем подумать.
Итак, мы собираемся построить следующее:
- Реактивный модуль содержания для отображения карточек с географическими элементами.
- Реактивный модуль веб-карт для отображения географических элементов на карте.
- Реактивный пользовательский модуль для управления пользовательским контентом, избранным и настройками.
Позвольте мне прояснить: эта серия не предназначена для того, чтобы подробно показать, как все это построить, поскольку для этого потребуется абсурдное количество написания, поэтому рассматривайте эту настройку как общую основу для различных ключевых моментов, которые я считаю наиболее важными. для накопления многоразовых знаний - я буду делать.
Все эти модули будут очень слабо связаны (если не будут полностью разделены), а все операции CRUD будут выполняться серверным приложением (см. Приложение Node.js в реальный мир: то, о чем вам никогда не говорят - серия из 5 частей ). Мы также будем полагаться на магазин (Vuex) для управления состоянием.
Таким образом, в наших файлах .vue вы увидите код, подобный приведенному ниже:
Приведенный выше фрагмент позволяет получать контент из модуля хранилища Vuex с помощью поставщика, если контент уже не находится в кеше клиента. Файл .vue ничего не знает о том, какой инструмент делает запрос (я использую Axios, но это может быть другой) или о конкретном вызове API, который необходим . Ему нужен только параметр конфигурации и поставщик, которые являются частью базового API.
Последний был прикреплен к прототипу экземпляра Vue с использованием пространства имен (здесь $ i, «i» означает Iperiago, мою компанию, если вам интересно). Теперь вы можете кое-где прочитать, что присоединение к прототипу экземпляра Vue было бы помечено как плохая практика. По моему скромному мнению, пока вы используете очень ограниченный набор пространств имен (здесь только одно), это нормально.
Весь этот подход позволит нам абстрагировать наши вызовы API в одном месте, полностью отделенным от Vue или инфраструктуры пользовательского интерфейса. Кроме того, использование хранилища Vuex означает, что каждый побочный эффект для всего приложения (модификации состояния приложения) при получении контента также не связан с компонентом.
Почему? Поскольку компоненты должны относиться к пользовательскому интерфейсу (вы можете увидеть в приведенном выше коде то, что выглядит как индикатор выполнения), и ничего больше - без управления состоянием и без конкретной реализации API.
В основном мы будем следовать этим рекомендациям в нашем приложении, пытаясь добиться еще большей развязки между компонентами, используя слоты, глобальные миксины и другие удобные функции Vue, пытаясь сохранить управляемость и читаемость нашего кода.
Теперь важное замечание. Возможно, вы слышали, что у Vue.js довольно быстрая кривая обучения, что, несомненно, верно, и вы, естественно, можете подумать, что использование Vue.js вместе с фреймворком пользовательского интерфейса упростит задачу.
Конечно, это сделает работу намного быстрее и удобнее, но если вы разберетесь с реальным веб-приложением, все будет не так просто, вам придется поставить немного поработать для этого.
Придется принять множество решений, в основном связанных с наилучшим сочетанием хорошей архитектуры программного обеспечения и хорошего пользовательского интерфейса, также будет много времени написание тестов. , что совсем нетривиально, и их будет трудно решить, а также предостережения (Система реактивности Vue.js великолепна, но, я могу вас заверить, вы столкнетесь с любыми несколькими оговорками, которые система имеет меньше времени, необходимого для запуска ваших автоматических тестов, и, если вы не подготовитесь, вы можете застрять на какое-то время).
Не бойтесь, поскольку эта серия статей призвана помочь вам справиться со всеми этими проблемами и, возможно, сэкономит вам дни драгоценного времени на развитие. Создание веб-приложения также доставляет массу удовольствия и может даже стимулировать вас еще больше, если вы способны быстро преодолевать проблемы. Так что наслаждайтесь поездкой!
- Как организовать код, назвать файлы и написать простой, читаемый, интуитивно понятный клиентский код в соответствии с хорошими руководящими принципами кодирования?
- Как эффективно использовать магазин Vuex?
- Когда и как использовать события, слоты Vue и миксины Vue?
- Сколько компонентов нужно настроить, как создать компоненты-оболочки и как решить, следует ли разделять компонент на несколько или нет?
- Как абстрагироваться от сторонних API?
- Как управлять аутентификацией и маршрутизацией?
Часть 3 о:
- Как решить проблемы с реактивностью?
- Как писать как модульные, так и сквозные тесты?
- Как справляться с ошибками?
Часть 4 (скоро):
- Как настроить согласованный пользовательский интерфейс?
- Как обрабатывать проверку формы?
- Как реализовать эффективные функции поиска?
Часть 5 (скоро):
- Как оптимизировать производительность и размер пакета и развернуть его в продакшене?
- Как комментировать код и создавать полезную документацию?
- Как выйти за пределы бесконечности?
Следите за Частью 1!
PS / Один небольшой отказ от ответственности на случай, если вы не заметили: английский не является моим родным языком, поэтому я прошу прощения за любую ошибку, которую я совершаю (или уже совершил).
