Полезные видео о фронтенде. Подпишись на Rutube

Хорошие практики и шаблоны проектирования для Vue Composables

год назад·1 мин. на чтение

Composables (composition API) можно использовать для хранения основной бизнес-логики (например, вычислений, действий, процессов), поэтому они являются важной частью приложения. К сожалению, в командах не всегда есть соглашения для написания composables.

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

Общие шаблоны проектирования

На мой взгляд, лучшим источником информации о шаблонах для создания composables на самом деле является документация Vue.js, с которой вы можете ознакомиться здесь.

Базовый composable

В документации Vue показан следующий пример компонуемого useMouse:

// mouse.js
import { ref, onMounted, onUnmounted } from 'vue'

// по соглашению имена composable функций начинаются с "use"
export function useMouse() {
  // состояние инкапсулировано и управляется самим composable
  const x = ref(0)
  const y = ref(0)

  // composable может обновлять состоянием
  function update(event) {
    x.value = event.pageX
    y.value = event.pageY
  }

  // composable также может иметь доступ к жизненному циклу родительского компонента
  // для установки и очистки эффектов
  onMounted(() => window.addEventListener('mousemove', update))
  onUnmounted(() => window.removeEventListener('mousemove', update))

  // отдаем состояние наружу как возвращаемое значение
  return { x, y }
}

Позже это можно использовать в компоненте следующим образом:

<script setup>
import { useMouse } from './mouse.js'

const { x, y } = useMouse()
</script>

<template>Mouse position is at: {{ x }}, {{ y }}</template>

Асинхронные composables

Для получения данных Vue рекомендует следующую компонуемую структуру:

import { ref, watchEffect, toValue } from 'vue'

export function useFetch(url) {
  const data = ref(null)
  const error = ref(null)

  watchEffect(() => {
    // обнуляем состояние перед запросом
    data.value = null
    error.value = null

    // toValue() разворачивает потенциальные рефы или геттеры
    fetch(toValue(url))
      .then((res) => res.json())
      .then((json) => (data.value = json))
      .catch((err) => (error.value = err))
  })

  return { data, error }
}

Затем это можно использовать в компоненте следующим образом:

<script setup>
import { useFetch } from './fetch.js'

const { data, error } = useFetch('...')
</script>

Соглашения composable

Основываясь на приведенных выше примерах, вот контракт, которому должны следовать все composables:

Имена composable файлов должны начинаться с use, например useSomeAmazingFeature.ts
Он может принимать входные аргументы, которые могут быть примитивными типами, такими как строки, или может принимать ссылки и геттеры, но для этого требуется использовать вспомогательное средство toValue
Composable должен возвращать значение ref, к которому можно получить доступ после деструктурирования composable, например const { x, y } = useMouse()
Composables могут содержать глобальное состояние, к которому можно получить доступ и изменить в приложении.
Composable может вызвать побочные эффекты, такие как добавление прослушивателей событий окна, но их следует очищать при отключении компонента.
Composables следует вызывать только в <script setup> или в хуке setup(). В этих контекстах их также следует называть синхронно. В некоторых случаях их также можно вызывать в обработчиках жизненного цикла, таких как onMounted()
Composables могут вызывать другие composables внутри
Composables должны заключать в себе определенную логику, а когда они слишком сложны, их следует извлекать в отдельные composables для облегчения тестирования.

Tree shaking — обязательная оптимизация производительности при сборке JavaScript приложения. В этой статье мы углубимся в то, как именно это работает и как сделать модули более компактными и производительными.

Прежде чем начать нам нужно понять, какие типы модулей есть в экосистеме JavaScript. Приложения на JavaScript усложнились и возросло количество выполняемых ими задач. Стала очевидной необходимость разделения таких задач на изолированные области. Эти подзадачи мы называем модулями. Их основная цель — предотвратить повторение кода и переиспользовать код.

Что такое tree shaking?

Проще говоря, tree shaking означает удаление недостижимого кода (также известного как мертвый код) из пакета. В переводе tree shaking переводится как встряхивание дерева. Почему? Проведем аналогию. Можно представить свое приложение в виде дерева. Исходный код и библиотеки, которые вы фактически используете, представляют собой зеленые, живые листья дерева. Мертвый код представляет собой коричневые мертвые листья дерева, которые появляются осенью. Чтобы избавиться от опавших листьев, нужно встряхнуть дерево, чтобы они опали.

Этот термин был впервые популяризирован в сообществе фронтенд разработчиков команды Rollup. Но авторы всех динамических языков боролись с этой проблемой гораздо раньше. Идея алгоритма встряхивания дерева восходит как минимум к началу 1990-х годов. В области JavaScript tree shaking стал возможным со времен спецификации ECMAScript модулей (ESM) в ES2015, известной как ES6. С тех пор tree shaking была включена по умолчанию в большинстве сборщиков, потому что они уменьшают размер результирующего кода без изменения поведения программы. Основная причина этого заключается в том, что ESM являются статическими по своей природе. Давайте разберем, что это значит.

ES модули и CommonJS

CommonJS предшествует спецификации ESM. Он появился на несколько лет раньше. Он появился чтобы решить проблему отсутствия поддержки переиспользуемых модулей в экосистеме JavaScript. В CommonJS есть функция require(), которая извлекает внешний модуль на основе предоставленного пути и добавляет его в область видимости во время выполнения. Функция require является такой же функцией, как и любая другая функция. Это делает ее достаточно сложной для оценки результата вызова во время компиляции. Кроме того, возможно добавление вызовов require в любом месте кода — в вызове другой функции, в операторах if/else, в операторах switch и т. д.

В результате широкого внедрения CommonJS архитектуры, спецификация ESM остановилась на новой архитектуре, в которой модули импортируются и экспортируются с помощью соответствующих ключевых слов import и export. Поэтому больше никаких вызовов функций для добавления модулей. ESM также разрешает только объявления верхнего уровня, их вложение в какую-либо другую структуру невозможно. Это и делает его статичным. ESM не зависят от запуска во время выполнения.

Область применения и побочные эффекты

Есть еще одно препятствие, которое нужно преодолеть, чтобы избежать раздувания кода: побочные эффекты (сайд эффекты, side effects). Считается, что функция имеет побочные эффекты, когда она изменяет или зависит от факторов, внешних по отношению к области выполнения. Функция с побочными эффектами считается нечистой (impure function). Чистая функция (pure function) всегда будет давать один и тот же результат при каждом запуске, независимо от контекста или среды, в которой она была запущена.

const pure = (a: number, b: number): number => a + b
const impure = (c: number): number => window.foo.number + c

Сборщики стараются максимально оценить предоставленный код, чтобы определить, является ли модуль чистым. Но оценка кода во время компиляции или во время связывания может зайти слишком далеко. Поэтому предполагается, что пакеты с побочными эффектами не могут быть должным образом устранены, даже если они полностью недоступны. Из-за этого сборщики принимают ключ внутри файла package.json модуля, который позволяет разработчику заявить, не имеет ли модуль побочных эффектов. Таким образом, разработчик может отказаться от оценки кода и сказать сборщику, что код в конкретном пакете может быть исключен, если нет доступного импорта или оператора require, связывающего его. Это не только делает пакет более компактным, но также может ускорить время компиляции.

{
    "name": "some-package",
    "sideEffects": false
}

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

В дополнение к полю sideEffects также можно указать чистоту для каждого файла, добавляя встроенный комментарий /*@__PURE__*/ к вызову метода.

const x = */@__PURE__*/eliminated_if_not_called()

Эта встроенная аннотацию полезна для разработчика-потребителя. Она полезна в случае, если пакет не объявил sideEffects: false или в случае, если библиотека действительно представляет побочный эффект для определенного метода.

Оптимизация Webpack

Начиная с версии 4, Webpack требует все меньше конфигураций, используя при этом лучшие практики. Несколько плагинов было включено в ядро. Если вы не большой эксперт в webpack или если ваше приложение не содержит специфических сценариев, то tree shaking зависимостей — это вопрос всего одной строки. Файл webpack.config.js имеет корневое поле с именем mode. Всякий раз, когда значение этого свойства production, оно полностью оптимизирует ваши модули. Помимо устранения мертвого кода с помощью TerserPlugin, mode: production присвоит хэшированные имена для модулей и чанков, а также активирует следующие плагины:

flag dependency usage
flag included chunks
module concatenation
no emit on errors.

Не случайно все это происходит именно в production режиме. Вы не захотите, чтобы ваши зависимости были полностью оптимизированы в режиме разработки, потому что это значительно усложнит отладку. Поэтому я бы предложил использовать один из двух подходов. Для указания режима можно передать флаг режима в интерфейс командной строки Webpack:

# это значение перезапишет значение указанное в webpack.config.js
webpack --mode=production

Либо можно использовать переменную среды process.env.NODE_ENV в webpack.config.js:

mode: process.env.NODE_ENV === 'production' ? 'production' : development

В этом случае вы должны не забыть передать --NODE_ENV=production при развертывании приложения. Оба подхода являются абстракцией поверх известного плагина definePlugin из Webpack 3 и ниже. Какой вариант вы выберете, абсолютно не имеет значения.

Webpack 3 и ниже

Стоит отметить, что сценарии и примеры в разделе “Webpack 3 и ниже” могут не применяться к последним версиям Webpack и другим сборщикам. В этом разделе рассматривается использование UglifyJS 2 вместо Terser. UglifyJS — это пакет, из которого появился Terser, поэтому оценка кода между ними может различаться. Поскольку Webpack 3 и ниже не поддерживает свойство sideEffects в package.json, все пакеты должны быть полностью оценены, прежде чем код будет удален. Уже одно это делает подход менее эффективным, но также необходимо учитывать несколько предостережений.

Как упоминалось выше, компилятор не может сам определить, когда пакет входит в глобальную область. Но это не единственная ситуация, в которой он пропускает tree shaking. Есть более неочевидные сценарии. Рассмотрим пример пакета из документации Webpack:

// transform.js

import * as mylib from 'mylib';

export const someVar = mylib.transform({
  // ...
});

export const someOtherVar = mylib.transform({
  // ...
});

А это его использование:

// index.js

import { someVar } from './transforms.js';

// Use `someVar`...

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

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

Инструмент, который может помочь компилятору заставить tree shaking работать, называется babel-plugin-transform-imports. Он разделит все элементы и именованные экспорты на экспорты по умолчанию, что позволит оценивать модули по отдельности.

// до трансформации
import { Row, Grid as MyGrid } from 'react-bootstrap';
import { merge } from 'lodash';

// после трансформации
import Row from 'react-bootstrap/lib/Row';
import MyGrid from 'react-bootstrap/lib/Grid';
import merge from 'lodash/merge';

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

Поднятие (hoisting) и время компиляции

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

(function (modulesMap, entry) {
  // provided CommonJS runtime
})({
  "index.js": function (require, module, exports) {
     let { foo } = require('./foo.js')
     foo.doStuff()
  },
  "foo.js": function(require, module, exports) {
     module.exports.foo = {
       doStuff: () => { console.log('I am foo') }
     }
  }
}, "index.js")

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

// moduleA.js
let $moduleA$export$doStuff = () => ({
  doStuff: () => {}
})

// index.js
$moduleA$export$doStuff()

Этот подход полностью совместим с ESM; кроме того, это позволяет оценке кода легко обнаруживать модули, которые не вызываются, и удалять их. Недостаток этого подхода заключается в том, что во время компиляции требуется значительно больше времени, потому что он касается каждого оператора и сохраняет пакет в памяти во время процесса. Это важная причина, по которой производительность пакетов стала еще более серьезной проблемой и почему скомпилированные языки используются в инструментах для веб-разработки. Например, esbuild — это сборщик, написанный на Go, а SWC — это компилятор TypeScript, написанный на Rust, который интегрируется со Spark, сборщиком, также написанным на Rust.

Избегайте преждевременной транспиляции

Есть одна проблема, которая, к сожалению, довольно распространена и может иметь негативные последствия для tree shaking. Короче говоря, это происходит, когда вы работаете со специальными загрузчиками, интегрируя разные компиляторы в свой сборщик. Распространенными комбинациями являются TypeScript, Babel и Webpack — во всех возможных сочетаниях. И у Babel, и у TypeScript есть собственные компиляторы, и соответствующие загрузчики позволяют разработчику использовать их для упрощения интеграции. И в этом кроется скрытая угроза.

Эти компиляторы достигают вашего кода до оптимизации кода. И по умолчанию или из-за неправильной настройки эти компиляторы часто выводят модули CommonJS вместо ESM. Как упоминалось в предыдущем разделе, модули CommonJS являются динамическими и, следовательно, не могут быть должным образом оценены для устранения мертвого кода. Этот сценарий становится все более распространенным в настоящее время с ростом «изоморфных» приложений (т. е. приложений, которые выполняют один и тот же код как на стороне сервера, так и на стороне клиента). Поэтому обязательно проверяйте код, который получает алгоритм оптимизации.

Tree shaking чеклист

Теперь, когда вы знаете все тонкости того как создаются бандлы и работает tree shaking, давайте выведем чеклист. Надеюсь, это сэкономит вам время и позволит оптимизировать не только производительность вашего кода, но, возможно, даже время сборки.

Используйте ESM, и не только в своей собственной кодовой базе, но также отдавайте предпочтение пакетам, которые сами выдают ESM.
Убедитесь, что вы точно знаете, какие из ваших зависимостей (если таковые имеются) не объявили sideEffects или не установили их в true.
Используйте встроенную аннотацию для объявления вызовов методов, которые являются чистыми при использовании пакетов с побочными эффектами.
Если вы выводите модули CommonJS, обязательно оптимизируйте свой пакет, прежде чем преобразовывать операторы импорта и экспорта.

Создание пакетов

Надеюсь, к этому моменту мы все согласимся с тем, что ESM был хорошей идеей в экосистеме JavaScript. К счастью, авторы пакетов могут принять надежные меры, чтобы облегчить своим пользователям быструю и беспрепятственную миграцию. С некоторыми небольшими дополнениями в package.json ваш пакет сможет сообщить сборщикам, какие среды поддерживает ваш пакет:

Включите экспорт ESM.
Добавьте "type": "module"
Укажите точку входа "module": "./path/entry.js"

И вот пример, который получается, когда соблюдаются все лучшие практики и вы хотите поддерживать как веб-среду, так и среду Node.js:

{
    // ...
    "main": "./index-cjs.js",
    "module": "./index-esm.js",
    "exports": {
        "require": "./index-cjs.js",
        "import": "./index-esm.js"
    }
    // ...
}

В дополнение к этому команда Skypack ввела показатель качества пакета в качестве эталона, чтобы определить, настроен ли данный пакет на долговечность и использует ли лучшие практики. @skypack/package-check может быть добавлен как devDependency в ваш пакет, чтобы легко выполнять проверки перед каждым релизом. Также рекомендую прочитать статью Создание tree-shaking библиотеки с Rollup и Vue, в ней также рассказано почему Webpack не подходит для создания tree-shaked библиотек.

Frontend Webpack Tree shaking