Микрофронтенд и Module Federation

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

Низкоуровневые концепции

Различаются два вида модулей - локальные и удаленные модули. Локальные модули — это обычные модули, которые являются частью текущей сборки. Удаленные модули (remote modules) — это модули, которые не являются частью текущей сборки, но загружаются во время выполнения из удаленного контейнера. Загрузка удаленных модулей считается асинхронной операцией. Невозможно использовать удаленный модуль без загрузки его чанка. Операция загрузки чанка обычно является вызовом import(), но также поддерживаются более старые конструкции, такие как require.ensure или require([...])). Контейнер создается с помощью точки входа контейнера, которая предоставляет асинхронный доступ к определенным модулям. Доступ к предоставляемым (expose) моделям разделен на два этапа:

1. загрузка модуля (асинхронная)
2. выполнение модуля (синхронная).

Шаг 1 будет выполнен во время загрузки чанка. Шаг 2 будет выполнен во время выполнения модуля, чередующегося с другими (локальными и удаленными) модулями. Таким образом, порядок выполнения не зависит от преобразования модуля из локального в удаленный или наоборот. Возможно вложение контейнеров. Контейнеры могут использовать модули из других контейнеров. Также возможны циклические зависимости между контейнерами.

Высокоуровневые концепции

Каждая сборка действует как контейнер, а также потребляет другие сборки в качестве контейнеров. Таким образом, каждая сборка может получить доступ к любому другому предоставленному модулю, загрузив его из своего контейнера. Общие модули — это модули, которые являются переопределяемыми и предоставляются в качестве переопределений для вложенных контейнеров. Они обычно указывают на один и тот же модуль в каждой сборке, например, на одну и ту же библиотеку. Параметр packageName позволяет задать имя пакета для поиска requiredVersion. Он автоматически выводится для запросов модуля по умолчанию. Установите requiredVersion в false, когда автоматический вывод должен быть отключен.

Основные части

ContainerPlugin (низкий уровень)

Этот плагин создает дополнительную запись контейнера с указанными открытыми модулями.

ContainerReferencePlugin (низкий уровень)

Этот плагин добавляет конкретные ссылки на контейнеры как внешние и позволяет импортировать удаленные модули из этих контейнеров. Он также вызывает API override этих контейнеров для предоставления им переопределений. Локальные переопределения (через __webpack_override__ или override API когда сборка является контейнером) и указанные переопределения предоставляются всем контейнерам, на которые имеются ссылки.

ModuleFederationPlugin (высокий уровень)

ModuleFederationPlugin объединяет ContainerPlugin и ContainerReferencePlugin.

Какие цели преследует Module Federation

• Должна быть возможность предоставлять и использовать любой тип модуля, поддерживаемый webpack.
• При загрузке чанков должно загружаться все необходимое параллельно (за один запрос к серверу).
• Управление от потребителя к контейнеру
  • Переопределение модулей представляет собой однонаправленную операцию.
  • Родственные контейнеры не могут переопределять модули друг друга.
• Концепция должна быть независимой от среды.
  • Можно использовать в web, Node.js и т. д.
• Относительный и абсолютный запрос в shared:
  • Всегда будет предоставлен, даже если не используется.
  • Будет разрешаться относительно config.context.
  • Не использует requiredVersion по умолчанию.
• Запросы модулей в shared:
  • Предоставляются только тогда, когда они используются.
  • Будет соответствовать всем используемым равным запросам модулей в вашей сборке.
  • Предоставит все соответствующие модули.
  • Будет извлекать requiredVersion из package.json в этой позиции в графе.
  • Может предоставлять и использовать несколько различных версий при наличии вложенных node_modules.
• Запросы модулей с / в shared будут сопоставлять все запросы модулей с этим префиксом.

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

Отдельные сборки для каждой страницы

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

Библиотека компонентов в качестве контейнера

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

Динамические удаленные контейнеры

Интерфейс контейнера поддерживает методы get и init. init — это async метод, который вызывается с одним аргументом: объектом общей области (shared scope). Этот объект используется в качестве общей области в удаленном контейнере и заполняется предоставленными модулями от хоста. Его можно использовать для динамического подключения удаленных контейнеров к контейнеру хоста во время выполнения.

// init.js

(async () => {
  // Инициализирует общую область. Заполняет его предоставленными модулями 
  // из текущего билда и из удаленных билдов
  await __webpack_init_sharing__('default');
  const container = window.someContainer; // или получить контейнер откуда-либо еще
  // Проинициализируйте контейнер, он может предоставлять общие модули
  await container.init(__webpack_share_scopes__.default);
  const module = await container.get('./module');
})();

Контейнер пытается предоставить общие модули, но если общий модуль уже использовался, предупреждение и предоставленный общий модуль будут проигнорированы. Контейнер может по-прежнему использовать его в качестве запасного варианта. Таким образом, вы можете динамически загружать A/B-тест, который предоставляет другую версию общего модуля. Убедитесь, что контейнер загружен, прежде чем пытаться динамически подключить удаленный контейнер. Пример:

// init.js

function loadComponent(scope, module) {
  return async () => {
    // Инициализирует общую область. Заполняет его предоставленными модулями 
    // из текущего билда и из удаленных билдов
    await __webpack_init_sharing__('default');
    const container = window[scope]; // или получить контейнер откуда-либо еще
    // Проинициализируйте контейнер, он может предоставлять общие модули
    await container.init(__webpack_share_scopes__.default);
    const factory = await window[scope].get(module);
    const Module = factory();
    return Module;
  };
}

loadComponent('abtests', 'test123');

Динамические удаленные модули на основе промисов

Как правило, удаленные модули настраиваются с использованием URL-адресов, как в этом примере:

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'host',
      remotes: {
        app1: 'app1@http://localhost:3001/remoteEntry.js',
      },
    }),
  ],
};

Но вы также можете передать промис в этот модуль, который будет зарезолвлен во время выполнения. Вы должны зарезолвить этот промис с помощью любого модуля, который соответствует интерфейсу get/init, описанному выше. Например, если вы хотите передать, какую версию fedarated модуля вы должны использовать, с помощью параметра запроса вы можете сделать что-то вроде следующего:

module.exports = {
  plugins: [
    new ModuleFederationPlugin({
      name: 'host',
      remotes: {
        app1: `promise new Promise(resolve => {
      const urlParams = new URLSearchParams(window.location.search)
      const version = urlParams.get('app1VersionParam')
      // Эта часть зависит от того как вы планируете хостить
      // и версионировать ваши federated модули
      const remoteUrlWithVersion = 'http://localhost:3001/' + version + '/remoteEntry.js'
      const script = document.createElement('script')
      script.src = remoteUrlWithVersion
      script.onload = () => {
        // внедренный скрипт загружен и доступен через объект window
        // теперь можно зарезолвить Promise
        const proxy = {
          get: (request) => window.app1.get(request),
          init: (arg) => {
            try {
              return window.app1.init(arg)
            } catch(e) {
              console.log('remote container already initialized')
            }
          }
        }
        resolve(proxy)
      }
      // внедрим этот скрипт с src с версионированным remoteEntry.js
      document.head.appendChild(script);
    })
    `,
      },
      // ...
    }),
  ],
};

Обратите внимание, что при использовании этого API необходимо зарезолвить объект, содержащий API get/init.

Динамический publicPath

Установка publicPath

Можно разрешить хосту задавать publicPath удаленного модуля во время выполнения, предоставляя метод из этого удаленного модуля. Этот подход особенно полезен при подключении независимо развернутых дочерних приложений по подпути домена узла. Сценарий: У вас есть хост приложение, размещенное на https://my-host.com/app/*, и дочернее приложение, размещенное на https://foo-app.com. Дочернее приложение также монтируется на хост-домене, следовательно, ожидается, https://foo-app.com будет доступно через https://my-host.com/app/foo-app, а запросы https://my-host.com/app/foo-app/* перенаправляются https://foo-app.com/* через прокси-сервер. Пример:

// webpack.config.js (удаленный)

module.exports = {
  entry: {
    remote: './public-path',
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'remote', // это имя должно совпадать с именем точки входа
      exposes: ['./public-path'],
      // ...
    }),
  ],
};

public-path.js (remote)

export function set(value) {
  __webpack_public_path__ = value;
}

// src/index.js (host)

const publicPath = await import('remote/public-path');
publicPath.set('/your-public-path');

//bootstrap app  e.g. import('./bootstrap.js')

Вывод publicPath из скрипта

Можно вывести publicPath из тега script из document.currentScript.src и задать его с переменной __webpack_public_path__ во время выполнения. Пример:

// webpack.config.js (удаленный)

module.exports = {
  entry: {
    remote: './setup-public-path',
  },
  plugins: [
    new ModuleFederationPlugin({
      name: 'remote', // this name needs to match with the entry name
      // ...
    }),
  ],
};

setup-public-path.js (удаленный)

// вычислите publicPath и установите его в  __webpack_public_path__
__webpack_public_path__ = document.currentScript.src + '/../';

Существует также значение 'auto', доступное для output.publicPath, которое автоматически определяет publicPath для вас.

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

1. Можете ли вы описать ситуацию, когда вам пришлось оптимизировать React приложение, чтобы повысить его производительность? Как вы это сделали?

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

• Избегать ненужных повторных рендеров
• Использовать уникального идентификаторы при отображении списков
• Использование хуков, таких как useMemo и useCallback, для запоминания функций

2. Как вы справляетесь с управлением состоянием в большом React приложении?

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

• Redux
• Recoil
• Jotai
• Rematch

Когда использовать состояние?

Представьте, что вы создаете приложение со списком дел в React. Вы хотите отслеживать список задач, которые ввел пользователь, а также логическое значение, указывающее, загружает ли приложение в данный момент данные из API. Например, у вас может быть действие с именем ADD_TODO, которое добавляет новый элемент списка дел в массив, и редьюсер, который соответствующим образом обновляет состояние. У вас также может быть действие SET_LOADING, которое обновляет состояние загрузки. Другим примером может быть корзина для покупок, которая отслеживает товары внутри корзины, даже когда пользователь обновляет страницу или покидает ее. Если ваши данные передаются только из глобальной переменной в компоненты приложения, вы также можете реализовать хук useContext. Это хорошо работает для работы с темами интерфейса пользователя и реализации аутентификации.

3. Можете ли вы описать опыт работы со сложной структурой данных в приложении React? Как вы с этим справились?

Для работы со сложными структурами данных в приложении React вам может потребоваться использовать такие методы, как сопоставление вложенных данных (маппинг, mapping), использование рекурсивных компонентов для визуализации данных с несколькими уровнями вложенности и оптимизация производительности с помощью таких методов, как React.memo. Также может быть полезно использовать библиотеки, такие как lodash, для управления и преобразования сложных структур данных. Например, функция debounce из библиотеки lodash, полезна для сокращения количества API запросов. Очевидно, что в React существует множество способов обработки сложных структур данных. Вот несколько сценариев, в которых вам, возможно, придется более осторожно подходить к обработке и представлению данных.

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

4. Как вы подходите к тестированию приложения React?

Важно иметь хорошую стратегию тестирования, чтобы убедиться, что ваше приложение React стабильно и работает правильно. Это может включать в себя комбинацию модульных тестов, интеграционных тестов и E2E тестов, а также такие методы, как снэпшот (snapshot) тестирование и TDD (разработка через тестирование).

• Используйте встроенные утилиты тестирования React, такие как React Testing Library и Enzyme, для проверки рендеринга и поведения компонентов.
• Напишите модульные тесты для отдельных компонентов React, чтобы убедиться, что они работают правильно изолированно.
• Напишите интеграционные тесты, чтобы проверить взаимодействие между несколькими компонентами и убедиться, что они правильно работают вместе.
• Используйте фреймворк для тестирования, такой как Jest, для запуска и организации тестов.
• Используйте снэпшот тестирование, чтобы убедиться, что рендеринг вашего компонента неожиданно не изменится.
• Используйте разработку через тестирование (TDD) для написания тестов перед написанием реализацией функций.
• Используйте библиотеку для мокирования, такую как Sinon.js, для мокирования зависимостей в ваших тестах.
• Напишите e2e тесты для тестирования приложения в целом, имитируя взаимодействие пользователя в реальном браузере.

5. Как вы обрабатываете асинхронные действия в React приложении?

Один из способов — использовать ключевые слова async и await, которые позволяют писать асинхронный код в синхронном стиле. Вот пример компонента, который выполняет асинхронный вызов API с использованием async и await: .

import React, { useState, useEffect } from 'react';

function MyComponent() {
 const [data, setData] = useState(null);

 useEffect(() => {
   async function fetchData() {
     const response = await fetch('https://example.com/get-data');
     const data = await response.json();
     setData(data);
   }
   fetchData();
 }, []);

 return (
   <div>
     {data ? (
       <div>{data.message}</div>
     ) : (
       <div>Loading...</div>
     )}
   </div>
 );
}

Другой способ обработки асинхронных функций в React — использование библиотеки, такой как axios или fetch, для выполнения API вызовов. Вот пример использования axios:

import React, { useState, useEffect } from 'react';
import axios from 'axios';

function MyComponent() {
 const [data, setData] = useState(null);

 useEffect(() => {
   async function fetchData() {
     const response = await axios.get('https://example.com/get-data');
     setData(response.data);
   }
   fetchData();
 }, []);

 return (
   <div>
     {data ? (
       <div>{data.message}</div>
     ) : (
       <div>Loading...</div>
     )}
   </div>
 );
}

Подробнее об асинхронности можно прочитать в статье Полное руководство по асинхронному JavaScript

6. Можете ли вы рассказать об отличиях между презентационным и контейнерным компонентами в React?

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

import React from 'react';

function Button(props) {
  return <button>{props.label}</button>;
}

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

import React, { Component } from 'react';
import Button from './Button';

class Form extends Component {
 state = {
   name: '',
 };

 handleChange = (event) => {
   this.setState({ name: event.target.value });
 };

 handleSubmit = (event) => {
   event.preventDefault();
   // отправка формы
 };

 render() {
   return (
     <form onSubmit={this.handleSubmit}>
       <label>
         Name:
         <input type="text" value={this.state.name} onChange={this.handleChange} />
       </label>
       <Button label="Submit" />
     </form>
   );
 }
}

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

7. Можете ли вы описать, как бы вы реализовали пагинацию в приложении React?

Вот один из способов реализации функции пагинации (перехода по страницам) в приложении React:

1. Определите общее количество необходимых страниц, исходя из объема имеющихся у вас данных и количества элементов, которые вы хотите отобразить на странице.
2. Добавьте переменную состояния page в свой компонент, чтобы отслеживать текущую страницу.
3. Напишите функцию, которая извлекает данные для определенной страницы и обновляет состояние компонента новыми данными.
4. Отобразите интерфейс пагинации, который может включать кнопки для перехода к следующей и предыдущей страницам, а также раскрывающийся список для выбора конкретной страницы.
5. Добавьте обработчики событий для элементов компонента пагинации, которые вызывают функцию выбора с соответствующим номером страницы.

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

8. Как вы обрабатываете роутинг на стороне клиента в приложении React?

Существует несколько способов обработки маршрутизации на стороне клиента в приложении React. Одним из популярных способов является использование библиотеки react-router-dom, которая предоставляет компонент <Router> для обработки маршрутизации и набор компонентов <Route> для определения маршрутов в вашем приложении. Вот пример того, как вы можете использовать react-router-dom для обработки маршрутизации на стороне клиента в приложении React: Установите библиотеку react-router-dom.

npm install react-router-dom

Импортируйте компоненты <Router> и <Route> из react-router-dom.

import { BrowserRouter as Router, Route } from 'react-router-dom';

Оберните свое приложение компонентом <Router>.

<Router>
  <App />
</Router>

Определите маршруты с помощью компонента <Route>. Компонент <Route> принимает проп path, указывающее путь для маршрута, и проп component, указывающий компонент для отображения при совпадении маршрута.

<Route exact path="/" component={Home} />
<Route path="/about" component={About} />
<Route path="/users/:id" component={User} />

Компонент <Route> будет отображать указанный компонент, когда текущий URL-адрес соответствует пути маршрута. Вы можете использовать проп exact, чтобы указать, что маршрут должен сопоставляться только тогда, когда путь точно совпадает с текущим URL-адресом. Вы также можете использовать компонент <Link> из react-router-dom для создания ссылок, которые перемещаются между маршрутами в вашем приложении.

import { Link } from 'react-router-dom';
...
<Link to="/about">About</Link>

9. Можете ли вы рассказать о преимуществах использования React Context API?

React Context API — отличная альтернатива передаче текущих данных без передачи пропсов из родительского компонента. Это может быть особенно полезно в случаях, когда у вас есть глубоко вложенная структура компонентов или если вы хотите передать данные компоненту, который находится на много уровней ниже по дереву. Некоторые преимущества использования React Context API включают:

Упрощает prop drilling

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

Облегчает обмен данными между компонентами

Если у вас есть состояние, которое необходимо разделить между несколькими компонентами, Context API может упростить это, не поднимая состояние до общего предка.

Улучшает производительность

Поскольку Context API не использует React Virtual DOM для передачи данных между компонентами, он может быть более эффективным, чем использование пропсов. Это может быть особенно полезно в случаях, когда вы передаете большие объемы данных или часто выполняете повторный рендеринг.

Увеличивает повторное использование кода

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

Итоги

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