Видео курс по Svelte

1. Что такое Svelte и как он устроен?

В этом уроке проинициализируем default проект на Svelte и рассмотрим структуру default проекта. Смотреть на Rutube

2. Как устроен Компонент в Svelte?

В этом уроке рассмотрим компоненты Svelte, пропс (props, $$props, $$restProps, export let prop), реактивность SvelteJS, блоки script и style, изоляцию стилей и :global() Смотреть на Rutube

3. Жизненный цикл Svelte компонента

В этом видео рассматриваем методы жизненного цикла компонентов Svelte, а именно onMount, onDestroy, beforeUpdate, afterUpdate, а также функция tick. Смотреть на Rutube

4. HTML шаблоны в Svelte

В этом уроке рассмотрим cинтаксис HTML шаблонов Svelte, а именно if, each, await, key, а также html и debug. Смотреть на Rutube

5. Как работать с событиями в Svelte?

В этом уроке по Svelte рассматриваем работу с событиями в Svelte, а именно директиву on, модификаторы событий, переброс событий, createEventDispatcher и т.д. Смотреть на Rutube

6. Байндинги и Привязки - Svelte Bindings

В этом уроке рассмотрим привязки в Svelte, синтаксис и директиву bind:, привязки к компонентам и т.д. Смотреть на Rutube

7. Хранилище Svelte Store

В этом уроке рассмотрим store в Svelte и разновидности хранилищ: writable store (хранилище для записи), readable store (хранилище только для чтения), derived store (производные хранилища) и custom store (пользовательские хранилища). Смотреть на Rutube

8. Анимации и переходы в Svelte - Motion, Transition and Animation

В этом видео рассматриваем анимации в Svelte, а именно анимации значений (Svelte motion), анимации переходов (Svelte Transition), Svelte Animate, директивы transition, in, out и многое другое. Смотреть на Rutube

9. Действия и директива use - Svelte Actions

В этом видео рассматриваем Действия в Svelte, для чего они нужно и как ими пользоваться. Добавляем в проект директиву use, отправляем события из Действия и реализовываем функции действий - destroy и update. Смотреть на Rutube

10. Слоты - Svelte slots. Context Модуль - Svelte module context

В этом видео рассматриваем слоты в Svelte и работу с script c context="module". Смотреть на Rutube

11. API контекста - Svelte Context API

В этом видео рассматриваем возможности контекста Svelte, функции setContext, getContext и hasContext, а также применение CSS классов по условию. Смотреть на Rutube

12. Специальные элементы - Svelte Special elements

В этом видео рассматриваем специальные элементы в Svelte. Смотреть на Rutube Исходный код проекта

Прежде чем начать нам нужно понять, какие типы модулей есть в экосистеме 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 библиотек.