Webpack

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

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

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

Предыстория

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

Разработчиком игр (пока что) так я и не стал, но стал веб-разработчиком, имея на данный момент 8+ лет коммерческого опыта. Однажды на глаза попалась весьма интересная библиотека-фреймворк для создания пошаговых игр, документация которой была незамедлительно изучена. Предлагалось создавать такие игры, как крестики-нолики или шахматы, однако это показалось скучным и мне захотелось пойти дальше - сделать нечто посложнее и похожее на то, во что я играл ещё в детстве. Вероятно, старички заметят некоторое сходство финального результата с той игрой, на которую делался акцент.

Построение и прорисовка мира

Сперва было принято решение создать изометрический мир, который мог бы поддерживать бесконечную прокрутку по горизонтали. После тщательного изучения статей на тему "Как создавать изометрические миры" и им подобных, а также просмотра библиотек для JavaScript и React, которые якобы должны помогать выполнять данную задачу, дело перешло к практике.

Времени на это было потрачено немало и готовых подходящих решений так и не было найдено. Ну что ж, напишем своё. По сути весь наш мир это набор квадратиков-тайлов, которые находятся рядом друг с другом и на соседний квадратик можно перейти в восьми направлениях.

Сперва отрисуем ячейки мира построчно. Пускай они будут размером 64x64 пикселя. Далее развернём наш контейнер таким образом, чтобы он выглядел изометрично:

.rotate {  transform: rotateX(60deg) rotateZ(45deg);  transform-origin: left top;}

При имплементации данного подхода к отрисовке можно наблюдать, что необходимые нам "строки" мира на самом деле идут не прямо, а зигзагом, так как мы развернули нашу карту. Таким образом, каждую из ячеек необходимо позиционировать абсолютно с учетом текущего индекса строки, а также индекса колонки:

const cellOffsets = {};export function getCellOffset(n) {  if (n === 0) {    return 0;  }  if (cellOffsets[n]) {    return cellOffsets[n];  }  const result = 64 * (Math.floor(n / 2));  cellOffsets[n] = result;  return result;}

Использование:

import { getCellOffset } from 'libs/civilizations/helpers';// ...const offset = getCellOffset(columnIndex);// ...style={{  transform: `translateX(${(64 * rowIndex) + (64 * columnIndex) - offset}px) translateY(${(64 * rowIndex) - offset}px)`,}}

Для увеличения производительности нам необходимо перерисовывать только те ячейки карты, которые сейчас являются видимыми на экране. Для этого был использован компонент FixedSizeGrid из модифицированной версии библиотеки react-window с учетом нашего поворота и расположений ячеек, код которого здесь приводить не буду. Из того, что не получилось - это сделать бесконечную прокрутку мира. После изучений исходного различных библиотек для бесконечного скролла / слайдеров и тп. подходящего решения найдено не было. Что ж, значит наш мир будет с границами по всем бокам.

Графика

Для отображения поворотов наших юнитов, а также анимации атаки, используются png-спрайты. Поиск графических элементов занял очень большой промежуток времени, было очень сложно найти хотя бы какие-то картинки возможных юнитов для нашей игры. Изначально ещё до поиска игра выглядела вот так:

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

Локализация

Игра поддерживает 4 языка и, если честно, мне непонятно, зачем в несложных приложениях разработчики подключают массивные библиотеки типа react-i18next. Давайте напишем похожее кастомное решение, которое уместится в чуть более чем 100 строк с учетом красивой разметки кода, а также будет поддерживать определение языка девайса пользователя, переключение языков в реальном времени и сохранение последнего выбора пользователя. Здесь используется redux, однако данный код можно адаптировать и под другие реактивные хранилища. Да, здесь нет некоторых фишек больших библиотек типа поддержки переменных в строках, однако в таком проекте нам это и не нужно. И да, эту библиотеку можно использовать как легковесную замену react-i18next (или подобным) в уже существующем проекте.

import React, { Component } from 'react';import PropTypes from 'prop-types';import { connect } from 'react-redux';import get from 'lodash/get';import set from 'lodash/set';import size from 'lodash/size';import { emptyObj, EN, LANG, PROPS, langs } from 'defaults';import { getLang } from 'reducers/global/selectors';import en from './en';export function getDetectedLang() {  if (!global.navigator) {    return EN;  }  let detected;  if (size(navigator.languages)) {    detected = navigator.languages[0];  } else {    detected = navigator.language;  }  if (detected) {    detected = detected.substring(0, 2);    if (langs.indexOf(detected) !== -1) {      return detected;    }  }  return EN;}const options = {  lang: global.localStorage ?    (localStorage.getItem(LANG) || getDetectedLang()) :    getDetectedLang(),};const { lang: currentLang } = options;const translations = {  en,};if (!translations[currentLang]) {  try {    translations[currentLang] = require(`./${currentLang}`).default;  } catch (err) {} // eslint-disable-line}export function setLang(lang = EN) {  if (langs.indexOf(lang) === -1) {    return;  }  if (global.localStorage) {    localStorage.setItem(LANG, lang);  }  set(options, [LANG], lang);  if (!translations[lang]) {    try {      translations[lang] = require(`./${lang}`).default;    } catch (err) {} // eslint-disable-line  }}const mapStateToProps = (state) => {  return {    lang: getLang(state),  };};export function t(path) {  const { lang = get(options, [LANG], EN) } = get(this, [PROPS], emptyObj);  if (!translations[lang]) {    try {      translations[lang] = require(`./${lang}`).default;    } catch (err) {} // eslint-disable-line  }  return get(translations[lang], path) || get(translations[EN], path, path);}function i18n(Comp) {  class I18N extends Component {    static propTypes = {      lang: PropTypes.string,    }    static defaultProps = {      lang: EN,    }    constructor(props) {      super(props);      this.t = t.bind(this);    }    componentWillUnmount() {      this.unmounted = true;    }    render() {      return (        <Comp          {...this.props}          t={this.t}        />      );    }  }  return connect(mapStateToProps)(I18N);}export default i18n;

Использование:

import i18n from 'libs/i18n';// ...static propTypes = {  t: PropTypes.func,}// ...const { t } = this.props;// ...{t(['path', 'to', 'key'])}// ...или тоже самое, но слегка медленнее{t('path.to.key')}// ...export default i18n(Comp);

Мультиплеер

Игра поддерживает мультиплеер в реальном времени для устройств с Android 9 или выше (возможно, будет работать и на 8-м, однако данное предположение не проверялось) с рейтингом и таблицей лидеров.

Сам движок не поддерживает ходы в реальном времени, потому многопользовательский режим построен таким образом, что все события происходят в один и тот же ход, в это же время существуют кулдауны на определенные действия, которые реализованы через requestAnimationFrame. На Android 7 и ранее такой подход почему-то просто-напросто не работает.

Кастомный код библиотеки, которая регистрирует requestAnimationFrame, для интересующихся (не забывайте также, что после регистрации колбека его нужно и отрегистрировать, что обычно происходит по завершении колбека или на анмаут компонента):

import isFunction from 'lodash/isFunction';let lastTime = 0;const vendors = ['ms', 'moz', 'webkit', 'o'];for (let x = 0; x < vendors.length && !window.requestAnimationFrame; ++x) {  window.requestAnimationFrame = window[`${vendors[x]}RequestAnimationFrame`];  window.cancelAnimationFrame = window[`${vendors[x]}CancelAnimationFrame`] || window[`${vendors[x]}CancelRequestAnimationFrame`];}if (!window.requestAnimationFrame) {  window.requestAnimationFrame = (callback) => {    const currTime = new Date().getTime();    const timeToCall = Math.max(0, 16 - (currTime - lastTime));    const id = window.setTimeout(() => { callback(currTime + timeToCall); },      timeToCall);    lastTime = currTime + timeToCall;    return id;  };}if (!window.cancelAnimationFrame) {  window.cancelAnimationFrame = (id) => {    clearTimeout(id);  };}let lastFrame = null;let raf = null;const callbacks = [];const loop = (now) => {  raf = requestAnimationFrame(loop);  const deltaT = now - lastFrame;  // do not render frame when deltaT is too high  if (deltaT < 160) {    let callbacksLength = callbacks.length;    while (callbacksLength-- > 0) {      callbacks[callbacksLength](now);    }  }  lastFrame = now;};export function registerRafCallback(callback) {  if (!isFunction(callback)) {    return;  }  const index = callbacks.indexOf(callback);  // remove already existing the same callback  if (index !== -1) {    callbacks.splice(index, 1);  }  callbacks.push(callback);  if (!raf) {    raf = requestAnimationFrame(loop);  }}export function unregisterRafCallback(callback) {  const index = callbacks.indexOf(callback);  if (index !== -1) {    callbacks.splice(index, 1);  }  if (callbacks.length === 0 && raf) {    cancelAnimationFrame(raf);    raf = null;  }}

Использование:

import { registerRafCallback, unregisterRafCallback } from 'client/libs/raf';// ...registerRafCallback(this.cooldown);// ...componentWillUnmount() {  unregisterRafCallback(this.cooldown);}

Стандартная имплементация Lobby из библиотеки движка мне не подходила, так как она открывала ещё одно новое websocket-подключение на каждый инстанс игры, но мне также нужно было передавать данные пользователя и таблицу лидеров по своему уже существующему websocket-подключению, потому, чтобы не плодить подключения, здесь снова было использовано собственное решение на основе библиотеки primus. На стороне клиента подключение хендлится сбилдженной библиотекой от примуса, которое также выложил на npm с именем primus-client. Вы можете сами сбилдить себе подобную клиентскую библиотеку для определенной версии примуса через функцию save на стороне сервера.

Видео геймплея многопользовательского режима можно наблюдать ниже:

Звук и музыка

В игре присутствует несколько звуков - старта игры, атаки и победы. Для проигрывания звука - также кастомная библиотека (для музыки - схожий подход):

import { SOUND_VOLUME } from 'defaults';const Sound = {  audio: null,  volume: localStorage.getItem(SOUND_VOLUME) || 0.8,  play(path) {    const audio = new Audio(path);    audio.volume = Sound.volume;    if (Sound.audio) {      Sound.audio.pause();    }    audio.play();    Sound.audio = audio;  },};export function getVolume() {  return Sound.volume;}export function setVolume(volume) {  Sound.volume = volume;  localStorage.setItem(SOUND_VOLUME, volume);}export default Sound;

Использование:

import Sound from 'client/libs/sound';// ...Sound.play('/mp3/win.mp3');

Сборка проекта

Сборка web-части осуществляется вебпаком. Однако тут нужно учитывать особенности путей к файлам, ведь в процессе разработке на локалхосте или на сервере в продакшене они являются относительными корня домена, а для приложения в Cordova наши файлы будут размещены по протоколу file:// и потому после сборки нам необходимо провести некоторые преобразования, а именно:

const replace = require('replace-in-file');const path = require('path');const options = {  files: [    path.resolve(__dirname, './app/*.css'),    path.resolve(__dirname, './app/*.js'),    path.resolve(__dirname, './app/index.html'),  ],  from: [/url\(\/img/g, /href="\//g, /src="\//g, /"\/mp3/g],  to: ['url(./img', 'href="./', 'src="./', '"./mp3'],};replace(options)  .then((results) => {    console.log('Replacement results:', results);  })  .catch((error) => {    console.error('Error occurred:', error);  });

Итоги

Приложение разрабатывалось в течении года, находится в Google Play Store с середины сентября, а значит уже прошло три месяца. Общее количество установок - 46, из которых ещё непонятно, сколько там на самом деле настоящих людей. Если коротко, то это провал. Однако был приобретен первичный опыт как разработки игр, так и мобильных приложений.

Из того, что было задумано, но не получилось:

1. Более сложный геймплей

2. Бесконечная прокрутка карты по горизонтали

3. Продвинутый ИИ компьютера

4. Поддержка мультиплеера на всех устройствах

Дальнейшие планы

Сейчас понятно, что подобные игры мало кому интересны, так что в прогрессе изучение Unity, и возможно через некоторое время появится ещё одна игра в жанре tactical rts.

Можно потыкать?

Можно. Для интересующихся - ссылка на приложение на Google Play Store.

P.S. Отдельное спасибо музыканту Anton Zvarych за предоставленную фоновую музыку.

Всем привет, меня зовут Иван и я фронтенд-разработчик.

На моём комментарии про микрофронтенды набралось целых три лайка, поэтому я решил написать статью с описанием всех шишек, что наш стрим набил и набивает в результате внедрения микрофронтендов.

Начнём с того, что ребята с Хабра (@artemu78, @dfuse, @Katsuba) уже писали про Module Federation, так что, моя статья - это не что-то уникальное и прорывное. Скорее, это шишки, костыли и велосипеды, которые полезно знать тем, кто собирается использовать данную технологию.

Причина

Причина, по которой решено было внедрять микросервисный подход на фронте, довольно простая - много команд, а проект один, нужно было как-то разделить зоны ответственности и распараллелить разработку. Как раз в тот момент, мне на глаза попался доклад Павла Черторогова про Webpack 5 Module Federation. Честно, это перевернуло моё видение современных веб-приложений. Я очень вдохновился и начал изучать и крутить эту технологию, чтобы понять, можно ли применить это в нашем проекте. Оказалось, всё что нужно, это дописать несколько строк в конфиг Webpack, создать пару компонентов-хелперов, и... всё завелось.

Настройка

Итак, что же нужно сделать, чтобы запустить микрофронтенды на базе сборки Webpack 5?

Для начала, убедитесь, что используете Webpack пятой версии, потому что Module Federation там поддерживается из коробки.

Настройка shell-приложения

Так как, до внедрения микрофронтендов, у нас уже было действующее приложение, решено было использовать его в качестве точки входа и оболочки для подключения других микрофронтендов. Для сборки использовался Webpack версии 4.4 и при обновлении до 5 версии возникли небольшие проблемы с некоторыми плагинами. К счастью, это решилось простым поднятием версий плагинов.

Чтобы создать контейнер на базе сборки Webpack и при помощи этого контейнера иметь возможность импортировать ресурсы с удаленных хостов добавляем в Webpack-конфиг следующий код:

const webpack = require('webpack');// ...const { ModuleFederationPlugin } = webpack.container;const deps = require('./package.json').dependencies;module.exports = {  // ...  output: {    // ...    publicPath: 'auto', // ВАЖНО! Указывайте либо реальный publicPath, либо auto  },  module: {    // ...  },  plugins: [    // ...    new ModuleFederationPlugin({      name: 'shell',      filename: 'shell.js',      shared: {        react: { requiredVersion: deps.react },        'react-dom': { requiredVersion: deps['react-dom'] },        'react-query': {          requiredVersion: deps['react-query'],        },      },      remotes: {        widgets: `widgets@http://localhost:3002/widgets.js`,      },    }),  ],  devServer: {    // ...  },};

Теперь нам нужно забутстрапить точку входа в наше приложение, чтобы оно запускалось асинхронно, для этого создаем файл bootstrap.tsx и кладем туда содержимое файла index.tsx

// bootstrap.tsximport React from 'react';import { render } from 'react-dom';import { App } from './App';import { config } from './config';import './index.scss';config.init().then(() => {  render(<App />, document.getElementById('root'));});

А в index.tsx вызываем этот самый bootstrap

import('./bootstrap');

В общем то всё, в таком виде уже можно импортировать ваши микрофронтенды - они указываются в объекте remotes в формате <name>@<адрес хоста>/<filename>. Но нам такая конфигурация не подходит, ведь на момент сборки приложения мы ещё не знаем откуда будем брать микрофронтенд, к счастью, есть готовое решение, поэтому возьмем код из примера для динамических хостов, так как наше приложение написано на React, то оформим хэлпер в виде React-компонента LazyService:

// LazyService.tsximport React, { lazy, ReactNode, Suspense } from 'react';import { useDynamicScript } from './useDynamicScript';import { loadComponent } from './loadComponent';import { Microservice } from './types';import { ErrorBoundary } from '../ErrorBoundary/ErrorBoundary';interface ILazyServiceProps<T = Record<string, unknown>> {  microservice: Microservice<T>;  loadingMessage?: ReactNode;  errorMessage?: ReactNode;}export function LazyService<T = Record<string, unknown>>({  microservice,  loadingMessage,  errorMessage,}: ILazyServiceProps<T>): JSX.Element {  const { ready, failed } = useDynamicScript(microservice.url);  const errorNode = errorMessage || <span>Failed to load dynamic script: {microservice.url}</span>;  if (failed) {    return <>{errorNode}</>;  }  const loadingNode = loadingMessage || <span>Loading dynamic script: {microservice.url}</span>;  if (!ready) {    return <>{loadingNode}</>;  }  const Component = lazy(loadComponent(microservice.scope, microservice.module));  return (    <ErrorBoundary>      <Suspense fallback={loadingNode}>        <Component {...(microservice.props || {})} />      </Suspense>    </ErrorBoundary>  );}

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

// useDynamicScript.ts  import { useEffect, useState } from 'react';export const useDynamicScript = (url?: string): { ready: boolean; failed: boolean } => {  const [ready, setReady] = useState(false);  const [failed, setFailed] = useState(false);  useEffect(() => {    if (!url) {      return;    }    const script = document.createElement('script');    script.src = url;    script.type = 'text/javascript';    script.async = true;    setReady(false);    setFailed(false);    script.onload = (): void => {      console.log(`Dynamic Script Loaded: ${url}`);      setReady(true);    };    script.onerror = (): void => {      console.error(`Dynamic Script Error: ${url}`);      setReady(false);      setFailed(true);    };    document.head.appendChild(script);    return (): void => {      console.log(`Dynamic Script Removed: ${url}`);      document.head.removeChild(script);    };  }, [url]);  return {    ready,    failed,  };};

loadComponent это обращение к Webpack-контейнеру, по сути - обычный динамический импорт.

// loadComponent.tsexport function loadComponent(scope, module) {  return async () => {    // Initializes the share scope. This fills it with known provided modules from this build and all remotes    await __webpack_init_sharing__('default');    const container = window[scope]; // or get the container somewhere else    // Initialize the container, it may provide shared modules    await container.init(__webpack_share_scopes__.default);    const factory = await window[scope].get(module);    const Module = factory();    return Module;  };}

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

// types.tsexport type Microservice<T = Record<string, unknown>> = {  url: string;  scope: string;  module: string;  props?: T;};

• url - имя хоста + имя контейнера (например, http://localhost:3002/widgets.js), с которого мы хотим подтянуть модуль

• scope - параметр name, который мы укажем в удаленном конфиге ModuleFederationPlugin

• module - имя модуля, который мы хотим подтянуть

• props - опциональный параметр, если вдруг наш микросервис требует пропсы, нужно их типизировать

Вызов компонента LazyService происходит следующим образом:

import React, { FC, useState } from 'react';import { LazyService } from '../../components/LazyService';import { Microservice } from '../../components/LazyService/types';import { Loader } from '../../components/Loader';import { Toggle } from '../../components/Toggle';import { config } from '../../config';import styles from './styles.module.scss';export const Video: FC = () => {  const [microservice, setMicroservice] = useState<Microservice>({    url: config.microservices.widgets.url,    scope: 'widgets',    module: './Zack',  });  const toggleMicroservice = () => {    if (microservice.module === './Zack') {      setMicroservice({ ...microservice, module: './Jack' });    }    if (microservice.module === './Jack') {      setMicroservice({ ...microservice, module: './Zack' });    }  };  return (    <>      <div className={styles.ToggleContainer}>        <Toggle onClick={toggleMicroservice} />      </div>      <LazyService microservice={microservice} loadingMessage={<Loader />} />    </>  );};

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

Так, с shell-приложением вроде разобрались, теперь нужно откуда-то брать наши модули.

Настройка микрофронтенда

Для начала проделываем все те же манипуляции что и в shell-приложении и убеждаемся, что версия Webpack => 5

Настраиваем ModuleFederationPlugin, но уже со своими параметрами, эти параметры указываем при подключении модуля в основное приложение.

// ...new ModuleFederationPlugin({      name: 'widgets',      filename: 'widgets.js',      shared: {        react: { requiredVersion: deps.react },        'react-dom': { requiredVersion: deps['react-dom'] },        'react-query': {          requiredVersion: deps['react-query'],        },      },      exposes: {        './Todo': './src/App',        './Gallery': './src/pages/Gallery/Gallery',        './Zack': './src/pages/Zack/Zack',        './Jack': './src/pages/Jack/Jack',      },    }),// ...

В объекте exposes указываем те модули, которые мы ходим отдать наружу, точку входа в приложение так же нужно забутстрапить. Если в микрофронтенде нам не нужны модули с других хостов, то компонент LazyService тут не нужен.

Вот и всё, получен работающий прототип микрофронтенда.

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

Проблемы

Когда удалось запустить это в нашем проекте я был доволен, нет, очень доволен, но это длилось недолго, после того как началась реальная работа над микрофронтендами, начали всплывать наши любимые подводные камни, а теперь поговорим он них подробнее.

Потеря контекстов в React-компонентах

Как только понадобилось работать с контекстом библиотеки react-router, то возникли проблемы, при попытке использовать в микрофронтенде хук useLocation, например, приложение вылетало с ошибкой.

Для взаимодействия с бэкендом мы используем Apollo, и хотелось, чтобы ApolloClient объявлялся только единожды в shell-приложении. Но при попытке из микрофронтенда просто использовать хук useQuery, в рантайме приложение вылетало с такой же ошибкой как и для useLocation.

Экспериментальным путём было выяснено, для того чтобы контексты правильно работали, нужно в микрофронтендах использовать версию npm-пакета не выше, чем в shell-приложение, так что за этим нужно внимательно следить.

Дублирование UI-компонентов в shell-приложении и микрофронтенде

Так как разработка ведётся разными командами, есть шанс, что разработчики напишут компоненты с одинаковым функционалом и в shell-приложении и в микрофронтенде. Чтобы этого избежать, есть несколько решений:

1. Выносить UI-компоненты в отдельный npm-пакет и использовать его как shared-модуль

2. "Делиться" компонентами через ModuleFederationPlugin

В принципе, у обоих подходов есть свои плюсы, но мы выбрали первый, потому что так удобнее и прозрачнее управлять библиотекой компонентов. Да и саму технологию Module Federation хотелось использовать как механизм для построения микрофронтендов, а не аналог npm.

Заключение

Пока что выглядит так, что переход на Webpack 5 Module Federation решает проблему, которая стояла перед нашим стримом, а именно - разделение зоны ответственности и распараллеливание разработки. При этом, нет больших накладных расходов при разработке, а настройка довольно проста даже для тех, кто не знаком с этой технологией.

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

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

Полезные ссылки

Репозиторий из примера

Документация Module Federation в доках Webpack 5

Примеры использования Module Federation

Плейлист по Module Federation на YouTube

Некоторые необходимые инструменты для rock-star разработчика

Привет, Хабр. В рамках набора на курс "React.js Developer" подготовили перевод материала.

Всех желающих приглашаем на открытый демо-урок "Webpack и babel". На занятии рассмотрим современные и мощные фишки JavaScript Webpack и Babel. Пошагово покажем, как с нуля создать проект на React, используя Webpack. Присоединяйтесь!

ReactJS по умолчанию обладает высокой производительностью. Но время от времени у вас появляется шанс сделать его еще лучше. И замечательное сообщество React придумало для этого несколько фантастических библиотек.

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

Давайте начнем.

. . .

1. React Query

Известно, что React Query, библиотека управления состоянием для React, отсутствует.

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

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

Преимущества

• Автоматическое кэширование

• Автоматическое обновление данных в фоновом режиме

• Значительно сокращает объем кода

До использования React Query

Вот пример для получения данных с помощью нашего пользовательского хука. Он даже не поддерживает кэширование.

const useFetch = (url) => {  const [data, setData] = useState();  const [isLoading, setIsLoading] = useState(false);  const [error, setError] = useState(false);   useEffect(() => {    const fetchData = async () => {      setIsError(false);      setIsLoading(true);      try {        const result = await fetch(url);        setData(result.data);      } catch (error) {        setError(error);      }      setIsLoading(false);    };    fetchData();  }, [url]);    return {data , isLoading , isError}}

После (использования) React Query

Вот код, если мы хотим использовать React Query. Посмотрите, какой он маленький.

import { useQuery } from 'react-query'const { isLoading, error, data } = useQuery('repoData', () =>    fetch(url).then(res =>res.json()  ))

Посмотрите, насколько сильно сократился наш код.

. . .

2. React Hook Form

React Hook Form - это современная библиотека обработки форм, которая может поднять эффективность работы вашей формы на совершенно новый уровень.

Преимущества

• Уменьшает объем кода

• Сокращает ненужный ре-рендеринг.

• Легко интегрируется с современными библиотеками пользовательского интерфейса (UI)

Ниже приведен пример, демонстрирующий, как React Hook Form может улучшить качество кода.

Без React Hook Form

Вот пример создания формы авторизации вручную.

function LoginForm() {  const [email, setEmail] = React.useState("");  const [password, setPassword] = React.useState("");  const handleSubmit = (e: React.FormEvent) => {    e.preventDefault();    console.log({email, password});  }    return (    <form onSubmit={handleSubmit}>          <input        type="email"        id="email"        value={email}        onChange={(e) => setEmail(e.target.value)}      />            <input        type="password"        id="password"        value={password}        onChange={(e) => setPassword(e.target.value)}      />          </form>  );}

С помощью React Form

Вот тот же пример с React Hook Form.

function LoginForm() {  const { register, handleSubmit } = useForm();    const onSubmit = data => console.log(data);     return (    <form onSubmit={handleSubmit(onSubmit)}>      <input {...register("email")} />      <input {...register("password")} />      <input type="submit" />    </form>  );}

Выглядит аккуратно и в то же время эффективно. Попробуйте.

. . .

3. React Window

React Window используется для рендеринга длинных списков. Представьте, что у вас есть список из 1 000 элементов. На экране отображаются только десять, но ваш код пытается визуализировать 1000 элементов одновременно.

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

Ручной рендеринг 1 000 элементов

import React, {useEffect, useState} from 'react';const names = [] // 1000 namesexport const LongList = () => {    return <div>       {names.map(name => <div> Name is: {name} </div>)}     <div/>}

Но этот код рендерит 1000 элементов одновременно, хотя на экране можно увидеть не более 10-20 элементов.

Использование React Window

Теперь давайте используем React Window.

import { FixedSizeList as List } from 'react-window'; const Row = ({ index, style }) => <div style={style}> Name is {names[index]}</div> const LongList = () => (  <List    height={150}    itemCount={1000}    itemSize={35}    width={300}  >    {Row}  </List>);

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

. . .

4. React LazyLoad

Ленивая загрузка - это техника, используемая для загрузки только того, что вам нужно. Таким образом, она повышает производительность, не расходуя без необходимости вычислительные мощности.

React LazyLoad - это библиотека, специально созданная для этой цели. Вы просто оборачиваете свой компонент, а эта библиотека позаботится обо всем остальном.

Преимущества

• Повышенная производительность

• Поддерживает рендеринг на стороне сервера

Без LazyLoad

Вот пример, в котором мы загружаем пять изображений вручную.

import React from 'react';const ImageList = () => {    return <div>    <img src ='image1.png' />    <img src ='image2.png' />    <img src ='image3.png' />    <img src ='image4.png' />    <img src ='image5.png' />  </div>}

С LazyLoad

Вот тот же пример с компонентом LazyLoad.

import React from 'react';import LazyLoad from 'react-lazyload';const ImageList = () => {    return <div>    <LazyLoad> <img src ='image1.png' /> <LazyLoad>    <LazyLoad> <img src ='image2.png' /> <LazyLoad>    <LazyLoad> <img src ='image3.png' /> <LazyLoad>    <LazyLoad> <img src ='image4.png' /> <LazyLoad>    <LazyLoad> <img src ='image5.png' /> <LazyLoad>  </div>}

. . .

5. Почему вы выполняете рендеринг (Why Did You Render)

Ненужный рендеринг может навредить производительности ваших React-приложений. Но иногда мы делаем это, даже не подозревая.

Этот замечательный пакет, Why Did You Render, помогает нам найти проблемы с производительностью и решить их. Вы просто включаете его в любом компоненте, и он сообщает вам, почему именно происходит рендеринг.

Ниже представлен компонент с возникающими проблемами рендеринга.

import React, {useState} from 'react'const WhyDidYouRenderDemo = () => {    console.log('render')        const [user , setUser] = useState({})    const updateUser = () => setUser({name: 'faisal'})    return <>        <div > User is : {user.name}</div>        <button onClick={updateUser}> Update </button>    </>}export default WhyDidYouRenderDemo

После включения эта библиотека будет записывать в консоль следующий результат.

Из этого журнала видно, что мы обновляем объект с одним и тем же значением, что плохо для производительности.

. . .

6. Reselect

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

Reselect решает эту проблему, меморизуя значения и передавая только то, что необходимо.

Преимущества (из документации)

• Селекторы могут вычислять производные данные, что позволяет Redux хранить минимально возможное состояние.

• Селекторы эффективны. Селектор не пересчитывается, если один из его аргументов не изменился.

• Селекторы являются составными. Они могут быть использованы в качестве входных данных для других селекторов.

Пример

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

import { createSelector } from 'reselect'const shopItemsSelector = state => state.shop.itemsconst subtotalSelector = createSelector(  shopItemsSelector,  items => items.reduce((subtotal, item) => subtotal + item.value, 0))const exampleState = {  shop: {    items: [      { name: 'apple', value: 1.20 },      { name: 'orange', value: 0.95 },    ]  }}

. . .

7. Deep Equal

Deep Equal - это известная библиотека, которую можно использовать для сравнения. Это очень удобно. Ведь в JavaScript, несмотря на то, что два объекта могут иметь одинаковые значения, они считаются разными, поскольку указывают на разные области памяти.

Вот почему мы видим следующий результат.

const user1 = {    name:'faisal'}const user2 ={    name:'faisal'}const normalEqual = user1 === user2 // false

Но если нужно проверить равенство (для мемоизации), то это становится затратной (и сложной) операцией.

Если мы используем Deep Equal, то это повышает производительность в 46 раз. Ниже приведен пример того, как мы можем это сделать.

var equal = require('deep-equal');const user1 = {    name:'faisal'}const user2 ={    name:'faisal'}const deepEqual = equal(user1 , user2); // true -> exactly what we wanted!

. . .

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

Оставляйте комментарии, если у вас на примете есть другие. Хорошего дня!

Ресурсы

1. Веб-сайт React Query

2. Веб-сайт React Hook Form

3. Примеры React Window

4. Пакет Why Did You Render

5. Пакет React Lazy Load

6. Reselect Репозиторий

7. Пакет Deep Equal

Узнать подробнее о курсе "React.js Developer"

Смотреть открытый онлайн-урок "Webpack и babel"

В первой, второй и третьей частях мои коллеги рассказали, как и почему мы распиливали монолит.

Если коротко, то мы создали решение, которое позволило в рамках одной открытой страницы браузера запускать несколько независимых Angular-приложений, шарить между ними данные, управлять роутингом и аутентификацией. Мы научились бороться с утечками памяти и решать конфликты глобальных стилей приложений. Но одна проблема оставалась открытой каждое приложение несло в своем банде Angular, RxJS, zone.js и т. д. И в этой статье я расскажу, как мы ее решили.

Исследование

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

Итак, дано:

• десятки приложений, созданных с помощью Angular CLI или nx;

• доступ к конфигурации webpack через кастомные билдеры;

• артефакты сборок webpack каждого приложения;

• одна страница браузера.

Минимальная цель: запустить дочерние приложения на Angular, на котором уже работает Frame Manager.

Мы выделили для себя четыре гипотетических варианта решения проблемы:

1. Monorepo.

2. Micro application like a package.

3. Webpack Externals.

4. Webpack Module Federation.

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

Monorepo & Micro app like a package

Monorepo это подход, когда все приложения и библиотеки хостятся в одном репозитории.

Micro app like a package имеется в виду подход, когда каждое приложение собирается как npm-пакет и устанавливается в host-приложение.

Плюсы и минусы обоих подходов схожи (поэтому они и объединены в одном пункте).

Минусы

• Максимально возможная оптимизация бандла средствами Angular.

• Одни и те же версии библиотек у всех приложений.

• Отсутствие костылей с инициализацией.

Плюсы

• Всегда нужно релизить все.

• Миграции всех приложений при апдейте зависимостей.

• Много инфраструктурных изменений.

Вывод напрашивается сам (хотя он был понятен еще до осознания этих плюсов/минусов) оба решения совершенно нам не подходят.

Webpack Externals

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

Плюсы

• Можно добиться экстремально маленького бандла. То есть взять и исключить вообще все внешние библиотеки, оставив только код самого приложения.

Минусы

• Исключенные библиотеки все равно нужно поставлять.

• Ничего не умеет из коробки

И опять неутешительный вывод нам необходимо решение чуть более сложное чем просто вырезать Angular из бандла.

Webpack Module Federation

Webpack Module Federation это подход, когда несколько отдельных сборок формируют одно приложение. Эти отдельные сборки не должны иметь зависимости друг от друга, поэтому их можно разрабатывать и развертывать индивидуально. Звучит многообещающе!

Плюсы

• Приложения остаются самодостаточными

• Архитектурно ничего не меняется

Минусы

• На момент исследования Angular не поддерживал webpack 5. Сейчас поддерживает экспериментально.

• На момент исследования никто не знал, когда Angular будет поддерживать webpack 5. На момент публикации, можно сказать, ничего не изменилось.

Итого: нестабильность, неопределённость и разочарование.

Результат исследования

Нам не подошло ни одно из существующих решений.

Исследование 2.0

Да, мы запустили еще одно исследование, но уже на основе результатов предыдущего мы составили список требований к будущему решению:

1. Приложения остаются самодостаточными. Каждое приложение продолжает так же независимо разрабатываться и имеет возможность самостоятельно запускаться как изолированно в iframe, так и без него.

2. Архитектурные изменения минимальны. Решение быстро и безболезненно интегрируется в любое приложение без глобальных изменений в организации кода и кодовой базы.

3. Приемлемое время и сложность имплементации.

4. Фолбэки. В этом пункте под фолбэками мы имеем в виду возможность приложения самостоятельно догрузить библиотеку для работы, если никакое другое приложение этой библиотекой еще не поделилось.

5. Библиотеки разных версий живут в своих бандлах.

В итоге этого исследования решение все-таки было найдено и через три дня уже был готов прототип.

@tinkoff/shared-library-webpack-plugin

Мы сделали webpack-плагин, который отвечает всем нашим требованиям. Если коротко, то плагин добавляет еще одну сущность в бандлы, которую мы назвали shared chunks. Эти сущности умеют использовать все приложения, собранные с помощью плагина. Если подробнее, то стоит начать с основных сущностей webpack.

Основные сущности webpack, которые выделили мы:

• Runtime отвечает за запуск приложения, поставляет такие функции, как require, также умеет загружать lazy chunks и т. д.

• Entries чанки, содержащие точку входа приложения.

• Lazy chunks ленивые чанки, загружаемые в приложение по требованию.

Плагин добавляет еще одну сущность:

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

Как выглядит сборка на примере Angular

Допустим, мы имеем два приложения, сгенерированных с помощью Angular CLI. С помощью любого кастомного билдера с поддержкой модификации конфигурации webpack и в оба приложения добавляем плагин со следующими настройками:

В настройках мы указываем, что приложение будет делиться всеми используемыми пакетами Angular (@angular/** ), а также zone.js. Артефакты такой сборки будут выглядеть примерно так.

Здесь мы видим, что каждый пакет Angular выделен в свой чанк, как и библиотека zone.js. Когда первое приложение загрузится, оно запросит все свои чанки, включая Angular и zone.js, и запустится.

При загрузке второго приложения будут запрошены runtime, main и polyfills. И приложение запустится. Никакой повторной загрузки Angular и zone.js. Второе приложение использует уже загруженные ранее экземпляры.

Как плагин работает

При сборке плагин:

1. Анализирует ресурсы и ищет библиотеки, которые указаны в настройках.

2. Выделяет библиотеки для шаринга в отдельные чанки (те самые shared chunks), хэширует имена с учетом версии.

3. Учит entries и runtime работать с shared chunks и сообщает каждому entry, какие shared chunks ему нужны для работы.

Как загружается приложение

1. На клиенте загружается runtime и entries. Тут все стандартно.

2. Каждая точка входа проверяет наличие обязательных для запуска шареных библиотек и сообщает о результатах runtime.

3. Runtime скачивает недостающие библиотеки и маркирует их как загруженные.

4. Runtime запускает приложение.

Кажется, что все просто. Но, как правило, просто только для автора кода. И то только первые пару месяцев.

А что насчет библиотек с разными версиями?

При формировании имен чанков плагин учитывает версию библиотеки. По умолчанию мы считаем, что каждая библиотека придерживается семантического версионирования и фикс версию можно упустить.

Это значит, что для модулей @angular/core@10.0.0 и @angular/core@10.0.1 будет сформировано одинаковое имя angularCore-10.0. Мы видим, что фикс-версия просто отсутствует. Именно поэтому чанки, имеющие одинаковые имена, грузятся единожды.

Если третье приложение имеет в зависимостях @angular/core/@9.x.x, то для shared chunk будет сформировано имя angularCore-9.x. Понятно, что в таком случае приложение загрузит свою версию библиотеки и будет работать с ней.

В случае проблем совместимости стандартное поведение формирования имени чанка можно изменить тремя параметрами: chunkname, suffix и separator.

Demo

Самым нетерпеливым ссылка на репозиторий

Дано:

• Хост-приложение. В него входит верхний тулбар и навигация слева.

• Два дочерних приложения. Каждое из них состоит из тулбара и некоего форматированного текста. В нашем случае это отрисованные md-файлы.

То есть на клиента загружается хост-приложение, которое в зависимости от роута подгружает дочернее приложение, предварительно подготавливая для него окружение.

Каждое приложение несет в себе свой экземпляр Angular, zone.js и т. д. Общий вес JavaScript после загрузки на клиента всех трех приложений составит 282.8kb в gzip.

В каждом приложении в сборку включаем плагин со следующими настройками:

const {  SharedLibraryWebpackPlugin,} = require('@tinkoff/shared-library-webpack-plugin');module.exports = {  plugins: [    new SharedLibraryWebpackPlugin({      libs: [        '@angular/core',        '@angular/common',        '@angular/common/http',        '@angular/platform-browser',        '@angular/platform-browser/animations',        '@angular/animations',        '@angular/animations/browser',        'zone.js/dist/zone',      ],    }),  ],};

Из конфигурации видно, что мы хотим пошарить между приложениями основные модули Angular и zone.js. Собираем, запускаем, открываем браузер и видим ужасную картину, когда размер хост-приложения увеличился на 58%(!).

Так происходит из-за отключения tree shaking для shared chunks. Причина отключения очень проста: заранее неизвестно, какую часть библиотеки будет использовать другое приложение.

Но при загрузке дочерних приложений мы видим совсем другую картину. Они стали грузить на 70% меньше JavaScript для запуска, так как Angular и zone.js уже были загружены. Общий размер загружаемого JavaScript упал на 19%.

Но можно ли еще уменьшить количество загружаемого кода? Оказывается, можно, стоит лишь чуть больше поиграть с webpack.

Используемые экспорты

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

В теории хост-приложение должно поставить на клиента шареную библиотеку, которая содержит объединение экспортов всех дочерних приложений. С этой мыслью мы добавили новую опцию в конфигурацию плагина usedExports, которая принимает массив строк. Фактически это перечисление экспортов из библиотеки, которые webpack должен включить в shared chunk в дополнение к уже используемым в приложении.

Итак, пора проверить, как это работает на нашем демо. Для этого мы модифицируем настройки плагина:

const {  SharedLibraryWebpackPlugin,} = require('@tinkoff/shared-library-webpack-plugin');module.exports = {  plugins: [    new SharedLibraryWebpackPlugin({      libs: [        { name: '@angular/core', usedExports: [] },        { name: '@angular/common', usedExports: [] },        { name: '@angular/common/http', usedExports: [] },        { name: '@angular/platform-browser', usedExports: ['DomSanitizer'] },        { name: '@angular/platform-browser/animations', usedExports: [] },        { name: '@angular/animations', usedExports: [] },        { name: '@angular/animations/browser', usedExports: [] },        'zone.js/dist/zone',      ],    }),  ],};

Пустой массив в usedExports означает, что webpack включит в shared chunk только экспорты, используемые в самом приложении. Опытным путем мы узнали, что для корректной работы одному из приложений понадобится DomSanitizer из модуля @angular/platform-browser, что мы тоже отражаем в конфигурации.

Собираем, запускаем, открываем браузер и видим

Хост-приложение грузит 129kb, что на 12kb больше, чем загружает хост-приложение, собранное без плагина. Но что с остальными приложениями? Они грузят все те же 23kb. Итого суммарно на клиента попадает на 38% меньше JavaScript кода. То есть было 282.8kb, а стало 174.6kb. Неплохо? Кажется, что немного лучше, чем неплохо, и даже хорошо! Для 20+ приложений со схожей архитектурой количество профита будет еще больше!

Ниже привожу табличку для наглядности сборки демо без плагина, с плагином и с usedExports.

Подведем итоги

При разработке плагина мы оглядывались на выявленные в ходе первого исследования требования и как результат все требования соблюдены и учтены (ставим мысленные пять чеков к пунктам из абзаца с требованиями). Количество загружаемого на клиента JavaScript-кода уменьшено. Дочерние приложения быстрее загружаются и инициируются, потребляют меньше памяти и вычислительных ресурсов. Мы перестали бояться webpack. И обогнали появление Webpack 5 в Angular на полгода. Тут также нужно учесть, что сейчас это даже не стабильная связка.

На этой ноте наше повествование о распиливании монолита официально закончено. Мы были рады поделиться своим опытом и будем рады почитать про ваш! Больше хардкорных тем в ленту Хабра!

Полезные ресурсы

Здесь оставлю ссылки на предыдущие части

Легенда

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

Вот на бумагу архитектор нанес первый блок. Сзади раздалась ругань. Это разработчики, спорили: Как лучше стартовать новый сервис и какой стартер выбрать. У архитектора по спине пронесся холодок. Не успела сложилась архитектура даже для Proof Of Concept, не то что для Minimal Valuable Product, но уже возникли препятствия. Выбор стартера наложит пока не очевидные рамки.

Одно было ясно, сборщик будет использоваться. Архитектор подошел к Team Lead и попросил использовать WebPack и чистый проект без стартера, так как по прошлым проектам с ним в той или иной мере знакомы разработчикам.

Мотивация

Каждый кто в 2020 использовал браузер - пользовался результатами сборки с помощью WebPack.

Среди разработчиков некоторые добавляли обработчик для специальных файлов или плагин для нужд проекта или использовали уже готовую конфигурацию, например в create-react-app.

Задач много и помнить параметры конфигурации смысла нет. Структура и часто используемые настройки сами отложатся в голове.

Готовые плагины и loader's сильно облегчают работу, задача на 95% заключается в прочтении первой страницы документации, чтобы сконфигурировать под конкретный проект. Даже в таком случае ошибки в синтаксисе случаются. Мало кто сходу вспомнит devtool или devtools. Некоторые директивы относились к другой версии WebPack. Учет этого будет полезным положить на плечи TypeScript.

Пару лет назад мне не нахватало подробного описания такой настройки, а на сайте самого WebPack только короткое описание: вот ссылка.

Особенности проекта в статье

В проекте для статьи нет цели написать всеобъемлющий мануал по настройке, будет базовый пример для backend и frontend.

Cервер будет отдавать статическую директорию с FE для нашего сайта. Сам же FE будет только выводить на страницу Hello World!. Зависимостями для BE будет node, для сборки webpack.

GitHub: тут

Структура директорий c описанием

Для удобства демонстрации я буду использовать моно-репозиторий с server и webapp в одном проекте

• ~/projectfolder/ # Корень проекта -- инициализирован с помощью yarn init

  • /apps # директория приложений

    • /server # директория backend -- инициализирована с помощью yarn init

      • /src # исходный код сервера

      • файлы конфигурации (части относящиеся к BE)

    • /webapp # директория frontend -- инициализирована с помощью yarn init

      • /src # исходный код браузерного приложения

      • файлы конфигурации (части относящиеся к FE)

    • /utils # расширенные утилиты

  • общие части конфигурации

Зависимости проекта

• Общие в директории ~/project_folder

yarn add -D @types/node @types/webpack concurrently cross-env nodemon ts-loader ts-node typescript webpack webpack-cli

• Для сервера в директории /apps/server нам не понадобится дополнительных зависимостей помимо тех что есть в общей директории

• Для веб-приложения в директории /apps/web_app нам понадобится html-webpack-plugin 5 версии так как он предназначен для использования с WebPack 5 версии. На Момент написания этот покет еще в beta доступе.

cd apps/web_appyarn add -D html-webpack-plugin@5

Настройки TypeScript

Браузер, server, и компьютер разработчика или runner - это три среды с личными особенностями:

Для сервера главное, nodeс помощью которой будет выполняться итоговый скрипт сервера. Что доступно в зависимости от версии наглядно показывается по ссылке:https://node.green

Конкретная настройка сервера apps/server/tsconfig.json не влияет на сборку, главное в конфигурации webpack указать правильны путь до файла для сборки сервера.

Для браузера, на конец 2020, лучше выбиратьES6если нет задачи поддерживать Internet Explorer 11. Хороший сайт для проверки доступных функций: https://caniuse.com

Файл: apps/web_app/tsconfig.json

Компьютер разработчика или runner где будет собираться проект тоже накладывает ограничения, которые в большинстве ситуаций легко устранимы. Для запуска также понадобиться конфигурация TS, она будет использоваться ts-node который будет запускаться под капотом webpack.

"compilerOptions": {    "module": "commonjs",    "target": "es5",    "esModuleInterop": true  }

Серверное приложение

Сервер для данной статьи предельно прост, раздачей файлов из одной папки. Код является копией статьи (ссылка) с сайта node, адаптированный под этот проект и с защитой от доступа к родительским папкам ..\..\secret в запрошенных файлах.

import { resolve, normalize, join } from 'path'import { createServer, RequestListener} from 'http'import { readFile } from 'fs' const webAppBasePath = '../web_app'; // Это путь до папки уже после build (в директории dist)const handleWebApp: RequestListener = (req, res) => {    const resolvedBase = resolve(__dirname ,webAppBasePath);    const safeSuffix = normalize(req.url || '')        .replace(/^(\.\.[\/\\])+/, '');    const fileLocation = join(resolvedBase, safeSuffix);    readFile(fileLocation, function(err, data) {        if (err) {            res.writeHead(404, 'Not Found');            res.write('404: File Not Found!');            return res.end();        }        res.statusCode = 200;        res.write(data);        return res.end();    });};const httpServer = createServer(handleWebApp)httpServer.listen("5000", () => {    console.info('Listen on 5000 port')})

Frontend приложение

Web приложение также предельно простое. В document.body монтируется простой <div id="root">Hello world!</div>

const rootNode = document.createElement('div')rootNode.setAttribute('id', 'root')rootNode.innerText = 'Hello World!'document.body.appendChild(rootNode)

Настройка WebPack

Теперь нам осталось только настроить webpack.

Для удобства конфигурацию можно разбить на файлы. А так как мы используем TS, то мы получаем синтаксис import {serverConfig} from "./apps/server/webpack.part"; из-за этого основной файл становится предельно коротким.

import {serverConfig} from "./apps/server/webpack.part";import {webAppConfig} from "./apps/web_app/webpack.part";import {commonConfig} from "./webpack.common";export default [    /** server  **/ {...commonConfig, ...serverConfig},    /** web_app **/ {...commonConfig, ...webAppConfig},]

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

Общая часть

Общая часть может содержать все что можно переиспользовать между различными конфигурациями. В нашем случае это поля mode и resolve. Обратите внимание, что у константы объявлена типизация const commonConfig: Configuration, тип взят из import {Configuration} from "webpack";.

import {Configuration, RuleSetRule} from "webpack";import {isDev} from "./apps/_utils";export const tsRuleBase: RuleSetRule = {    test: /\.ts$/i,    loader: 'ts-loader',}export const commonConfig: Configuration = {    mode: isDev ? 'development' : 'production',    resolve: {        extensions: ['.tsx', '.ts', '.js', '.json'],    },}

Также в этом файле лежит общая для проекта часть настройки правила для загрузки TS файлов const tsRuleBase: RuleSetRule, тип взят из import {RuleSetRule} from "webpack";.

isDev это простая проверка isDev = process.env.NODE_ENV === 'development'

Конфигурация FE и BE

Тут уже все максимально похоже на простую настройку webpack, только с подсказками благодаря типизации import {Configuration, RuleSetRule, WebpackPluginInstance} from "webpack";

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

import {Configuration, RuleSetRule, WatchIgnorePlugin, WebpackPluginInstance} from "webpack";import {join} from "path";import {tsRuleBase} from "../../webpack.common";const serverPlugins: WebpackPluginInstance[] = [    new WatchIgnorePlugin({        paths: [join(__dirname, '..', 'apps', 'web_app')]    })]const tsRuleServer: RuleSetRule = {    ...tsRuleBase,    options: {        configFile: join(__dirname, 'tsconfig.json')    }}export const serverConfig: Configuration = {    entry: join(__dirname, 'src', 'index.ts'),    output: {        path: join(__dirname, '..', '..', 'dist', 'server'),        filename: 'server.js'    },    target: 'node',    plugins: serverPlugins,    module: {        rules: [tsRuleServer]    }}

import {Configuration, RuleSetRule, WatchIgnorePlugin, WebpackPluginInstance} from "webpack";import HtmlWebpackPlugin from "html-webpack-plugin";import {join} from "path";import {tsRuleBase} from "../../webpack.common";const webAppPlugins: WebpackPluginInstance[] = [    new HtmlWebpackPlugin(),    new WatchIgnorePlugin({        paths: [join(__dirname, '..', 'apps', 'server')]    })]const tsRuleWebApp: RuleSetRule = {    ...tsRuleBase,    options: {        configFile: join(__dirname, 'tsconfig.json')    }}export const webAppConfig: Configuration = {    entry: join(__dirname, 'src', 'index.ts'),    output: {        path: join(__dirname, '..', '..', 'dist', 'web_app'),        filename: 'bundle.js'    },    target: 'web',    plugins: webAppPlugins,    module: {        rules: [tsRuleWebApp]    }}

Один из интересный моментов - это указание пути до файла конфигурации для ts-loader, выглядит это так configFile: join(__dirname, 'tsconfig.json'). Так как __dirname в каждом случае различен. То в случае backend все компилируется в целевую версию EcmaScript esnext, а для frontend в es6.

Заключение

Весь код приведенный в статью публикуется под "UNLICENSE". Что также указано в репозитории Github: тут.

Использование в проектах конфигурации через TS - это конечно не бизнес фича. Но привносит комфорт в процесс настройки. На небольших проектах это не так заметно, но если вы например используете micro-frontend c помощью ModuleFederationPlugin, то количество файлов конфигурации webpack растет с каждым микро-приложением и комфорт при настройке становится важен, тем более что время затраченное на именно TS тут минимальное.

PS. Хотелось бы узнать будет ли вам интересна настройка разработки через разворачивание в docker (для VSCode и JetBrains)

Легенда

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

Вот на бумагу архитектор нанес первый блок. Сзади раздалась ругань. Это разработчики, спорили: Как лучше стартовать новый сервис и какой стартер выбрать. У архитектора по спине пронесся холодок. Не успела сложилась архитектура даже для Proof Of Concept, не то что для Minimal Valuable Product, но уже возникли препятствия. Выбор стартера наложит пока не очевидные рамки.

Одно было ясно, сборщик будет использоваться. Архитектор подошел к Team Lead и попросил использовать WebPack и чистый проект без стартера, так как по прошлым проектам с ним в той или иной мере знакомы разработчикам.

Мотивация

Каждый кто в 2020 использовал браузер - пользовался результатами сборки с помощью WebPack.

Среди разработчиков некоторые добавляли обработчик для специальных файлов или плагин для нужд проекта или использовали уже готовую конфигурацию, например в create-react-app.

Задач много и помнить параметры конфигурации смысла нет. Структура и часто используемые настройки сами отложатся в голове.

Готовые плагины и loader's сильно облегчают работу, задача на 95% заключается в прочтении первой страницы документации, чтобы сконфигурировать под конкретный проект. Даже в таком случае ошибки в синтаксисе случаются. Мало кто сходу вспомнит devtool или devtools. Некоторые директивы относились к другой версии WebPack. Учет этого будет полезным положить на плечи TypeScript.

Пару лет назад мне не нахватало подробного описания такой настройки, а на сайте самого WebPack только короткое описание: вот ссылка.

Особенности проекта в статье

В проекте для статьи нет цели написать всеобъемлющий мануал по настройке, будет базовый пример для backend и frontend.

Cервер будет отдавать статическую директорию с FE для нашего сайта. Сам же FE будет только выводить на страницу Hello World!. Зависимостями для BE будет node, для сборки webpack.

GitHub: тут

Структура директорий c описанием

Для удобства демонстрации я буду использовать моно-репозиторий с server и webapp в одном проекте

• ~/projectfolder/ # Корень проекта -- инициализирован с помощью yarn init

  • /apps # директория приложений

    • /server # директория backend -- инициализирована с помощью yarn init

      • /src # исходный код сервера

      • файлы конфигурации (части относящиеся к BE)

    • /webapp # директория frontend -- инициализирована с помощью yarn init

      • /src # исходный код браузерного приложения

      • файлы конфигурации (части относящиеся к FE)

    • /utils # расширенные утилиты

  • общие части конфигурации

Зависимости проекта

• Общие в директории ~/project_folder

yarn add -D @types/node @types/webpack concurrently cross-env nodemon ts-loader ts-node typescript webpack webpack-cli

• Для сервера в директории /apps/server нам не понадобится дополнительных зависимостей помимо тех что есть в общей директории

• Для веб-приложения в директории /apps/web_app нам понадобится html-webpack-plugin 5 версии так как он предназначен для использования с WebPack 5 версии. На Момент написания этот покет еще в beta доступе.

cd apps/web_appyarn add -D html-webpack-plugin@5

Настройки TypeScript

Браузер, server, и компьютер разработчика или runner - это три среды с личными особенностями:

Для сервера главное, nodeс помощью которой будет выполняться итоговый скрипт сервера. Что доступно в зависимости от версии наглядно показывается по ссылке:https://node.green

Конкретная настройка сервера apps/server/tsconfig.json не влияет на сборку, главное в конфигурации webpack указать правильны путь до файла для сборки сервера.

Для браузера, на конец 2020, лучше выбиратьES6если нет задачи поддерживать Internet Explorer 11. Хороший сайт для проверки доступных функций: https://caniuse.com

Файл: apps/web_app/tsconfig.json

Компьютер разработчика или runner где будет собираться проект тоже накладывает ограничения, которые в большинстве ситуаций легко устранимы. Для запуска также понадобиться конфигурация TS, она будет использоваться ts-node который будет запускаться под капотом webpack.

"compilerOptions": {    "module": "commonjs",    "target": "es5",    "esModuleInterop": true  }

Серверное приложение

Сервер для данной статьи предельно прост, раздачей файлов из одной папки. Код является копией статьи (ссылка) с сайта node, адаптированный под этот проект и с защитой от доступа к родительским папкам ..\..\secret в запрошенных файлах.

import { resolve, normalize, join } from 'path'import { createServer, RequestListener} from 'http'import { readFile } from 'fs' const webAppBasePath = '../web_app'; // Это путь до папки уже после build (в директории dist)const handleWebApp: RequestListener = (req, res) => {    const resolvedBase = resolve(__dirname ,webAppBasePath);    const safeSuffix = normalize(req.url || '')        .replace(/^(\.\.[\/\\])+/, '');    const fileLocation = join(resolvedBase, safeSuffix);    readFile(fileLocation, function(err, data) {        if (err) {            res.writeHead(404, 'Not Found');            res.write('404: File Not Found!');            return res.end();        }        res.statusCode = 200;        res.write(data);        return res.end();    });};const httpServer = createServer(handleWebApp)httpServer.listen("5000", () => {    console.info('Listen on 5000 port')})

Frontend приложение

Web приложение также предельно простое. В document.body монтируется простой <div id="root">Hello world!</div>

const rootNode = document.createElement('div')rootNode.setAttribute('id', 'root')rootNode.innerText = 'Hello World!'document.body.appendChild(rootNode)

Настройка WebPack

Теперь нам осталось только настроить webpack.

Для удобства конфигурацию можно разбить на файлы. А так как мы используем TS, то мы получаем синтаксис import {serverConfig} from "./apps/server/webpack.part"; из-за этого основной файл становится предельно коротким.

import {serverConfig} from "./apps/server/webpack.part";import {webAppConfig} from "./apps/web_app/webpack.part";import {commonConfig} from "./webpack.common";export default [    /** server  **/ {...commonConfig, ...serverConfig},    /** web_app **/ {...commonConfig, ...webAppConfig},]

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

Общая часть

Общая часть может содержать все что можно переиспользовать между различными конфигурациями. В нашем случае это поля mode и resolve. Обратите внимание, что у константы объявлена типизация const commonConfig: Configuration, тип взят из import {Configuration} from "webpack";.

import {Configuration, RuleSetRule} from "webpack";import {isDev} from "./apps/_utils";export const tsRuleBase: RuleSetRule = {    test: /\.ts$/i,    loader: 'ts-loader',}export const commonConfig: Configuration = {    mode: isDev ? 'development' : 'production',    resolve: {        extensions: ['.tsx', '.ts', '.js', '.json'],    },}

Также в этом файле лежит общая для проекта часть настройки правила для загрузки TS файлов const tsRuleBase: RuleSetRule, тип взят из import {RuleSetRule} from "webpack";.

isDev это простая проверка isDev = process.env.NODE_ENV === 'development'

Конфигурация FE и BE

Тут уже все максимально похоже на простую настройку webpack, только с подсказками благодаря типизации import {Configuration, RuleSetRule, WebpackPluginInstance} from "webpack";

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

import {Configuration, RuleSetRule, WatchIgnorePlugin, WebpackPluginInstance} from "webpack";import {join} from "path";import {tsRuleBase} from "../../webpack.common";const serverPlugins: WebpackPluginInstance[] = [    new WatchIgnorePlugin({        paths: [join(__dirname, '..', 'apps', 'web_app')]    })]const tsRuleServer: RuleSetRule = {    ...tsRuleBase,    options: {        configFile: join(__dirname, 'tsconfig.json')    }}export const serverConfig: Configuration = {    entry: join(__dirname, 'src', 'index.ts'),    output: {        path: join(__dirname, '..', '..', 'dist', 'server'),        filename: 'server.js'    },    target: 'node',    plugins: serverPlugins,    module: {        rules: [tsRuleServer]    }}

import {Configuration, RuleSetRule, WatchIgnorePlugin, WebpackPluginInstance} from "webpack";import HtmlWebpackPlugin from "html-webpack-plugin";import {join} from "path";import {tsRuleBase} from "../../webpack.common";const webAppPlugins: WebpackPluginInstance[] = [    new HtmlWebpackPlugin(),    new WatchIgnorePlugin({        paths: [join(__dirname, '..', 'apps', 'server')]    })]const tsRuleWebApp: RuleSetRule = {    ...tsRuleBase,    options: {        configFile: join(__dirname, 'tsconfig.json')    }}export const webAppConfig: Configuration = {    entry: join(__dirname, 'src', 'index.ts'),    output: {        path: join(__dirname, '..', '..', 'dist', 'web_app'),        filename: 'bundle.js'    },    target: 'web',    plugins: webAppPlugins,    module: {        rules: [tsRuleWebApp]    }}

Один из интересный моментов - это указание пути до файла конфигурации для ts-loader, выглядит это так configFile: join(__dirname, 'tsconfig.json'). Так как __dirname в каждом случае различен. То в случае backend все компилируется в целевую версию EcmaScript esnext, а для frontend в es6.

Заключение

Весь код приведенный в статью публикуется под "UNLICENSE". Что также указано в репозитории Github: тут.

Использование в проектах конфигурации через TS - это конечно не бизнес фича. Но привносит комфорт в процесс настройки. На небольших проектах это не так заметно, но если вы например используете micro-frontend c помощью ModuleFederationPlugin, то количество файлов конфигурации webpack растет с каждым микро-приложением и комфорт при настройке становится важен, тем более что время затраченное на именно TS тут минимальное.

PS. Хотелось бы узнать будет ли вам интересна настройка разработки через разворачивание в docker (для VSCode и JetBrains)

Привет, меня зовут Ваня, недавно я выступил на CodeFest 11, где рассказал про путь Тинькофф Бизнеса на фронтенде от одного приложения к сотне. Но так как в ИT очень быстро все меняется, а ждать запись еще долго, сейчас я тезисно расскажу о нашем шестилетнем путешествии в дивный мир микрофронтенда!

Мою статью можно разбить на две части. В первой части вас ждет история развития через призму бизнеса. А во второй рассказ о том, как мы адаптировались к новым вызовам.

Этапы развития

1. Одно приложение на AngularJS в 20142015 годах.

2. Миграция на Angular2.

3. Утяжеление десяти приложений новой функциональностью.

4. Переход к микросервисам и разбиение на 100 приложений.

На дворе начало 2015 года. К нам приходит бизнес и говорит: Мы хотим сделать зарплатный проект! Посмотрите, что есть сейчас на рынке по технологиям, и сделайте. Выбираем AngularJS, быстро создаем приложение. Спустя некоторое время аппетиты вырастают, мы создаем еще два сервиса. На этот момент фронтенд-приложения никак не взаимодействуют друг с другом.

Компания растет, мы доходим до десяти приложений в 2017 году. Команды еще не так сильно разрослись, но уже чувствуется локализация некоторой экспертизы. Для шаринга информации выделяется особая роль архитектор. С одной стороны, это самый технически прокачанный человек, с другой евангелист наших подходов, который на одном языке общается как с бизнесом, так и с новичком в компании.

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

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

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

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

Сайдбар

Первые три приложения мы подружили между собой с помощью сайдбара.

В каждое приложение он встраивался с помощью ссылки на скрипт, который загружал на клиент полноценное приложение. Сайдбар отвечал за авторизацию, продукты клиента и текущий роутинг страницы, мог отправлять уведомления и загружал мессенджер на страницу. Как мы видим, довольно много возможностей у одного сервиса.

По технической части это iframe со всеми плюсами и минусами, о которых довольно подробно расписано в докладе Яндекса. Но больше всего нам не нравилась перезагрузка страницы на каждую смену продукта. Это мешало переиспользованию состояния клиента, требовало каждый раз обращаться к бекенду и добавляло некрасивые мерцания страницы при переходах.

Frame Manager

Именно рваные переходы мы убрали с появлением Frame Manager'а (далее буду называть его ФМ).

В отличие от сайдбара, который встраивался в приложение с помощью iframe, ФМ находился на странице всегда и сам встраивал в себя приложения.

Для клиента ФМ так же не заметен, как и сайдбар, но для нас он выполняет уже больше функций. Кроме рейтинга, списка продуктов и авторизации он может передавать состояние между приложениями, например через глобальный window. Пользователь больше не замечает, что ходит между несколькими отдельными приложениями, так как верхняя часть у него никуда не пропадает и визуально весь процесс выглядит как подгрузка контента на одну страницу.

В плане интеграции приложения тоже все поменялось:

• Раньше приложению-клиенту достаточно было подключить необходимый скрипт к себе в index.html.

• Теперь все приложения ФМа хранятся в отдельной конфигурации и используются как единый источник правды.

Минус этого подхода мы все равно остались с iframe, который нам не особо нравился из-за особенностей работы с ним.

Однажды через поддержку к нам обратились пользователи с ситуацией: Раньше у меня работал плагин для Google Chrome, а с недавнего времени именно на вашем сайте перестал. Почините, пожалуйста! Обычно на такие просьбы не реагируют: пользователь что-то себе установил пусть сам и разбирается. Но только не в нашей компании. Команда долго изучала вопрос, смотрела, какое окружение у клиента, версия браузера и все-все, но ответа так и не было. В итоге мы полностью повторили окружение, загрузили себе плагины и путем дебагинга установили, что данный плагин не работает, если у iframe динамически менять атрибут src или пересоздавать фрейм. К сожалению, мы так и не смогли исправить такое поведение, поскольку на этой концепции построено все взаимодействие ФМ и дочерних приложений.

Бесфрейм-менеджер

Однажды мы собрались и подумали: Несколько лет страдаем от iframe. Как перестать страдать? Давайте просто уберем его! Сказано сделано. Так и появился бесфрейм-менеджер с фантазией у нас, конечно, не фонтан ;-)

Ключевые отличия от предыдущей версии самописная изоляция и работа с микрофронтендом вместо фрейма. На мой взгляд, лучше всего мотивацию создания отражает слайд из моей презентации:

В решении три составляющие:

1. Webpack-плагин основа нашего решения, подробнее о которой можно прочитать в статье Игоря.

2. Angular builder обвязка для настройки и запуска плагина.

3. Angular schematics скрипт для упрощения работы с файловой структурой с помощью AST.

В 2021 году плагин становится менее актуальным, потому что вышел Webpack 5 с Module Federation, но напомню, что мы вели разработку в 2018 году, а Angular стал поддерживать последнюю версию вебпака лишь с двенадцатой версии, которая вышла 12 мая 2021 года. Мы пока не уверены, сможет ли MF заменить наше решение, и изучаем комбинацию подходов.

Что же касается других решений, на которые можно было перейти для отказа от iframe, то это Single SPA. Он всем хорош и очень популярен, но в плане Angular есть небольшой дисклеймер.

Мы понимали, что глобально менять концепцию фреймворка нам никто не даст, потому решили доделать имеющийся.

Что же касается Angular builder и schematics, то они нужны, чтобы разработчики, которые будут интегрировать наше решение к себе, не выполняли километровую инструкцию, а просто написали в консоли:

ng update @scripts/deframing

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

Тестирование

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

1. Можно прогонять тесты совместно с локальным ФМом. Так разработчики всегда могут быть уверены, что на текущей продовой сборке все работает и выглядит так, как и задумывалось.

2. Сам ФМ определяет несколько жизненно важных процессов, работоспособность которых гарантирует при любых условиях: это авторизация, роутинг, работа с данными приложений. Для этого создаются приложения-стабы (stub), суть которых подключиться к ФМу и выполнить одну из вышеперечисленных функций. То есть на каждое изменение кодовой базы ФМа будет гарантированно работать эта функция.

Ну и как же обойтись без описания багов, которые мы встретили на своем пути. Их тоже можно поделить глобально на две группы: накопление стилей и сторонние библиотеки.

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

.my-pretty-header {    display: none;}

Если у кого-то из следующих приложений есть такое же название класса, этот стиль применится так же!

Пример: диалог решил спрятаться под меню, чтобы пользователь не догадался, что от него требуется:

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

Сторонние библиотеки если на одной странице два и более приложения используют библиотеку, которая на старте создает новый инстанс, то получается такая картина:

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

Microzord

Вот мы и прошли шесть лет технического развития нашего решения. И что может быть лучше, чем поделиться этим опытом с сообществом? Все наработки будут публиковаться под npm scope @microzord с открытым кодом на Гитхабе.

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