предисловие
vue之火，不言而喻，框架给前端带来了方便，但是代码的漏洞也会很多。如果不加以注意和优化就会陷入不必要的性能、冗余等问题，所以我们有必要关注优化的重要性，下面我们将把常用的优化做一些总结和探索 我们将从以下几方面着手
Направление оптимизации
Лучшие практики
один,Направление оптимизации кода
Не существует выбора лучших технологий, есть только наиболее подходящие для бизнеса. В настоящее время наш бизнес упакован и построен с помощью gulp+webpack. На данный момент есть несколько болевых точек:
1. Избыточность кода.
Мы часто вводим большую библиотеку utils, на самом деле в этой библиотеке упоминается только метод, но вся библиотека запакована, а код избыточен и расточителен. По мере появления все большего количества файлов эта проблема будет становиться все более и более очевидной. Независимо от того, основано ли это на чистоте кода или его размере, оптимизация необходима.
2. Асинхронное управление потоком.
С развитием JS фронтенда мы стоим на плечах Даниэля и постепенно избавляемся от callback hell и ям различных асинхронных процессов. В настоящее время существует лучшее решение для асинхронных процессов «асинхронное/ожидающее решение». Node 7.6 официально поддерживает эту функцию, и сторона браузера также может быть унифицирована для достижения цели изоморфизма интерфейса и сервера. Четкое управление асинхронным процессом имеет положительное значение для понимания и поддержки командного кода.
3. Соблюдение чистоты кода.
Внедрите стрелочные функции, чтобы упростить код. Используйте функцию, при которой стрелочные функции не связывают это, чтобы решить проблему "дрейфа" этого.
два,Базовая оптимизация
Так называемая базовая оптимизация — это то, что делает любой веб-проект и является источником проблемы. HTML, CSS, JS — первое, что нужно оптимизировать
Соответствующий файлу .vue соответственно,<template>,<style>,<script>, давайте поговорим о том, что стоит оптимизировать в проекте vue по порядку
template
Семантические теги, избегание случайного вложения, разумное именование атрибутов и т. д. не обсуждаются в стандартных рекомендациях.
Часть шаблона помогает нам отображать структурированные данные, vue управляет просмотром данных, в основном обратите внимание на следующие моменты.
v-show, какой v-if использовать?
На мой взгляд, нам нужно думать о проблеме в двух измерениях:
- Первое измерение — это проблема разрешений.Поскольку речь идет о дисплеях, связанных с разрешениями, несомненно, будет использоваться v-if*.
- Второе измерение выбирается в соответствии с частотой кликов пользователя без ограничений разрешений, с использованием v-show для частого переключения и v-if для нечастого переключения.
Здесь следует упомянуть оптимизацию, чтобы уменьшить общее количество DOM на странице.Я предпочитаю использовать v-if, потому что это уменьшает количество DOM и ускоряет рендеринг первого экрана.Что касается производительности, я чувствую что процесс рендеринга переключения нельзя увидеть невооруженным глазом и он не повлияет на работу пользователя.
Не пишите слишком много выражений и суждений в шаблоне v-if="isShow && isAdmin && (a || b)", хотя такое выражение можно распознать, но оно не является долгосрочным решением, когда выглядит неудобный, соответствующим образом написанный в методах и вычисленный и инкапсулированный в метод, преимущество этого заключается в том, что нам удобно оценивать одно и то же выражение в нескольких местах, и другие элементы с теми же полномочиями могут вызывать один и тот же метод при оценке и отображении .
Добавление ключа Когда цикл называется подсадкой, ключ однозначно идентифицирует индивидуальный цикл, может использоваться E.G.item.idВ качестве ключа, если данные массива такие ['a', 'b', 'c', 'a'], очевидно, бессмысленно использовать:key="item", лучший способ - зациклить (item , index) в arr, затем :key="index" для обеспечения уникальности ключа.
style
Поместить файл стиля внутри или вне файла vue? Обсуждать бессмысленно.Смысл делить по модулям.Моя привычка класть внутрь vue файла,что удобно для написания кода.Это прыгать вверх-вниз в одном и том же файле.<style scopeed>Цель блокировки файла стиля очень проста. Как бы легко ни было использовать стандарт, это не избавит от проблем разработки несколькими людьми. Согласованные правила именования также могут конфликтовать. После блокировки области попробуйте использовать короткие правила именования, нет необходимости в .header-title__text и т. д. класс, получить его напрямую с .title.
Чтобы отличить его от предыдущего, поговорим о файле глобального стиля и о файле глобального стиля, постарайтесь его максимально абстрагировать.Так как он не повторяется в каждом компоненте, постарайтесь быть как можно более общим. чем лучше абстракция этой части, тем больше размер файла стиля. Чем меньше размер, тем выше коэффициент повторного использования. Рекомендуется поместить код, который переопределяет библиотеку компонентов, например стиль элемента, в файл global.
Не используйте макет с плавающей точкой. Я видел, как многие люди инкапсулируют .fl -- float: left в глобальный файл, а затем нужно .clear. Текущие браузеры не настолько слабы, чтобы использовать float для совместимости, они могут полностью сгибаться ., совместимость с сеткой общая, и функция может быть реализована в flex layout.Float принесет неприятности макету.Любой, кто его использовал, знает, что они не верят в яму объяснений.
Что касается других общих характеристик, то здесь я не буду вдаваться в подробности, есть много статей по теме.
script
Эта часть также является наиболее сложной для оптимизации, и я выскажу свое личное мнение.
При разработке несколькими людьми старайтесь поддерживать порядок методов в каждом компоненте export default {} согласованным, чтобы было удобно находить соответствующий метод. Я лично привык к данным, пропсам, хукам, часам, вычислениям, компонентам.
Что я хочу сказать о данных, так это инициализировать структуру данных как можно более подробно, с четкими именами, легкими для понимания и избегать бесполезных переменных. isEditing может фактически представлять два состояния, true или false. Не определяйте notEditing для управления display, это можно сделать в шаблоне в {{ isEditing ? Editing: save}}
При передаче значений в компоненты родитель-потомок props попробуйте: width="" :heigth="" Не делайте: option={}, преимущество уточнения в том, чтобы передать только те параметры, которые необходимо изменить, добавить данные введите реквизиты дочернего компонента, нужно ли его передавать, и значение по умолчанию. Это значение легко устранять ошибки и сделать значение более строгим.
Для хука полезно понимать смысл жизненного цикла, когда следует делать запрос, когда следует отменить метод и какие методы следует отменить. Просто и понятно, написано на официальном сайте.
Каждый метод в методах должен быть простым, делать только одну вещь, пытаться инкапсулировать короткие и повторно используемые методы, и не так просто иметь слишком много параметров. Если вы в значительной степени полагаетесь на разработку lodash, метод будет выглядеть намного проще, но цена будет заключаться в том, что общий размер пакета будет больше. Если в проекте используется только небольшая часть метода, вы можете импортировать loadsh локально. Если вы этого не сделаете Если вы не хотите использовать lodash, вы можете самостоятельно инкапсулировать файл util.js.
Какой вопрос использовать для просмотра и вычисления? Посмотрите на пример официального веб-сайта. Вычисляемое свойство в основном выполняет слой преобразования фильтра. Не добавляйте некоторые вызывающие методы. Роль наблюдения заключается в отслеживании изменений данных для изменения данных. или запускать такие события, как this.$store.dispatch('update', { ... })
3. Оптимизация компонентов
Компонентизация vue всем глубоко любима, в конце концов, разумно разобрать компоненты, это также зависит от размера проекта, небольшие проекты можно делать с несколькими компонентами, даже без vuex, axios и т. д. Если масштаб большой, его нужно разбить на компоненты, чем мельче, тем лучше, включая инкапсуляцию макета, кнопки, формы, окна подсказок, карусели и т. д. Рекомендуется прочитать код библиотеки компонентов Element. У вас нет времени писать такие детали, вы можете напрямую использовать библиотеку Element для оптимизации в нескольких точках.
Компоненты имеют четкое значение и занимаются только похожими делами. Чем выше возможность повторного использования, тем лучше, и чем мощнее конфигурация, тем лучше.
Самостоятельная инкапсуляция компонентов по-прежнему следует правилам настройки уточнения свойств.
Классификация компонентов, я обычно делю ее на три категории: страница, элемент страницы и макет, страница является частью управления маршрутизацией, элемент страницы принадлежит каждому блоку макета на странице, например баннеру, стороне и т. д., несколько страниц размещены в макете как минимум компоненты, которые появляются дважды, такие как значок, scrollTop и т. д.
оптимизация vue-router и vuex Помимо переключения маршрутов, vue-router больше всего использует логику обработки разрешений, я не буду здесь подробно останавливаться на управлении разрешениями, есть много связанных демок и статей, когда дело доходит до оптимизации, стоит упомянуть, что компоненты загружаются лениво.
Ссылка на официальный сайт указана выше, пример выглядит следующим образом.
const Foo = r => require.ensure([], () => r(require('./Foo.vue')), 'group-foo')
const Bar = r => require.ensure([], () => r(require('./Bar.vue')), 'group-foo')
const Baz = r => require.ensure([], () => r(require('./Baz.vue')), 'group-foo')
Этот код упаковывает три компонента Foo, Bar, Baz в файл фрагмента с именем group-foo, конечно, файл js
Остальное можно написать нормально.При загрузке сайта он автоматически проанализирует, какой чанк нужно загрузить.Хотя общий объем каждого пакета станет больше, но гораздо быстрее, просто глядя на скорость первого экрана запрос.
Есть несколько проблем и решений, с которыми сталкивается vuex.
Когда веб-сайт достаточно большой, под деревом состояний в корне находится много полей.Чтобы решить эту проблему, нам нужно модульизировать vuex.Официальный сайт предоставляет модульное решение, которое позволяет нам настраивать модули при инициализации vuex. Каждый модуль содержит состояние, действие и т. д., которые кажутся несколькими деревьями состояний, но на самом деле являются поддеревьями, основанными на корневом состоянии. После подразделения вся структура состояния понятна, и управлять гораздо удобнее.
Из-за гибкости vuex кодирование неоднородно, полный замкнутый циклstore.dispatch('action') -> action -> commit -> mutation -> getter -> computed, на самом деле часть промежуточных звеньев можно опустить, т.к. в документации API предусмотрены следующие методыmapState、mapGetters、mapActions、mapMutations, а затем вы можете напрямую вызвать любой шаг в компоненте, или вы можете назвать его так, как хочет проект. Когда проект большой, вы должны учитывать единство использования vuex. Мое предложение - запустить весь замкнутый цикл независимо от того, как простой процесс.Формируется унификация кода, что удобно для последующего управления.В моих компонентах разрешены только диспетчеризация и mapGetters, а весь остальной процесс осуществляется в папке vuex с именем store.
Основываясь на вышеизложенном, давайте поговорим о том, что делать в каждом процессе.Должны быть несоответствия между внешними и внутренними данными, или структурой данных, или именованием полей.Так на каком шаге должна логика данных преобразование будет обработано? Некоторые люди скажут, что любой шаг может быть достигнут, но это не так.
Перед отправкой отправки обработайте структуру данных и имена полей параметров, которые необходимо передать в компоненте
Когда дело доходит до действия, мы можем делать многое, потому что это поддерживает асинхронность, поддерживаетstate, rootState, commit, dispatch, getters，Видно, что ответственность большая.Во-первых, если бэкенду нужны какие-то данные в других модулях, их нужно интегрировать в исходные данные через значение rootState.Следующим шагом будет сделать запрос.Рекомендуется（async await + axios）, отфильтровать и преобразовать после получения данных, а затем отправить коммит на мутацию
Этот шаг заключается в обновлении преобразованных данных в состояние.Может быть процесс распределения данных (передача объекта для изменения значения ключей в нескольких состояниях), вы можете преобразовать структуру данных, но старайтесь не делать преобразование полей , В предыдущем шаге
На данный момент хранилище обновлено, используйте метод геттера, чтобы получить значение, токен: state => state.token, просто получите значение, постарайтесь не делать преобразование данных, суть в том, что нужно преобразовать, это то же самое поле используется в нескольких местах, но структура ситуации отличается (редко).
Используйте mapGetters в компоненте, чтобы получить соответствующее значение геттера.
В-четвертых, оптимизация упаковки
Спецификация кода и оптимизация упомянуты выше, а ключевая оптимизация упаковки описана ниже.Упакованный пакет поставщика некоторое время назад составляет 1,4 млн, а пакет приложения также имеет 270 тыс. Пакет приложения может быть решен путем отложенной загрузки компонентов. решить пакет вендора?
Некоторые люди задаются вопросом, не сжат ли он или пакет зависимостей не дедуплицирован.На самом деле все, что они сделали, это увидели 1,4 МБ.
Решение очень простое, при упаковке вендора не упаковывать vue, vuex, vue-router, axios и т.п., а использовать отечественный bootcdn для непосредственного внедрения его в index.html корневого каталога.
Например:
В вебпаке есть экстернал, который может игнорировать библиотеки, которые не нужно упаковывать
externals: {
'vue': 'Vue',
'vue-router': 'VueRouter',
'vuex': 'Vuex',
'axios': 'axios'
}
В это время пакет вендора будет очень маленьким.Если он недостаточно мал, другие библиотеки могут быть разделены.В это время количество запросов увеличено, но это намного быстрее, чем загрузка пакета 1.4M.
Пополнить: Проверьте представление упакованного файла:
# build for production and view the bundle analyzer report
npm run build --report
Суммировать
Оптимизация, обсуждаемая в этой статье, может решить некоторые проблемы с производительностью, в реальной разработке много нюансов, короче говоря, код пишется в соответствии со спецификациями, стиль кодирования команды максимально унифицирован, и большинство проблем с производительностью можно решить. думая больше о деталях.
Статья из личного блога Orangeorangexc.xyz/