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

Как передать пропсы React компоненту

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

Компоненты React используют пропсы (props) для связи друг с другом. Каждый родительский компонент может передавать некоторую информацию своим дочерним компонентам, предоставляя им пропсы. Пропсы могут напоминать атрибуты HTML, но вы можете передавать через них любое значение JavaScript, включая объекты, массивы и функции.

Содержание туториала по React Компоненты React используют пропсы (props) для связи друг с другом. Каждый родительский компонент может передавать некоторую информацию своим дочерним компонентам, предоставляя им пропсы. Пропсы могут напоминать атрибуты HTML, но вы можете передавать через них любое значение JavaScript, включая объекты, массивы и функции.

Известные пропсы

Пропсы — это информация, которую вы передаете тегу JSX. Например, className, src, alt, width и height — вот некоторые пропсы, которые вы можете передать <img>:

function Avatar() {
  return (
    <img
      className="avatar"
      src="https://example.com/userpic.jpg"
      alt="Userpic"
      width={100}
      height={100}
    />
  );
}

export default function Profile() {
  return <Avatar />;
}

Пропсы, которые вы можете передать тегу <img>, предопределены (ReactDOM соответствует стандартам HTML). Но вы можете передать любые пропсы своим собственным компонентам, таким как <Avatar>, чтобы настроить их.

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

В этом коде компонент Profile не передает никаких пропсов своему дочернему компоненту Avatar:

export default function Profile() {
  return <Avatar />;
}

Вы можете передать в Avatar некоторые пропсы в два этапа.

Шаг 1: Передайте пропсы дочернему компоненту

Во-первых, передайте некоторые пропсы в Avatar. Например, давайте передадим два пропса: person (объект) и size (число):

export default function Profile() {
  return (
    <Avatar person={{ name: 'User Name 1', imageId: '12345' }} size={100} />
  );
}

Если двойные фигурные скобки после person= вас смущают, помните, что они являются просто объектом внутри фигурных скобок JSX. Теперь вы можете прочитать эти пропсы внутри компонента Avatar.

Шаг 2: Прочтите пропсы внутри дочернего компонента

Вы можете прочитать эти пропсы, указав их имена - person, size - разделенные запятыми внутри ({ и }) непосредственно после function Avatar. Это позволяет использовать их внутри кода Avatar, как если бы вы использовали переменную.

function Avatar({ person, size }) {
  // person и size можно здесь использовть
}

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

// utils.js

export function getImageUrl(person, size = 's') {
  return 'https://example.com/' + person.imageId + size + '.jpg';
}

// App.js

import { getImageUrl } from './utils.js';

function Avatar({ person, size }) {
  return (
    <img
      className="avatar"
      src={getImageUrl(person)}
      alt={person.name}
      width={size}
      height={size}
    />
  );
}

export default function Profile() {
  return (
    <div>
      <Avatar
        size={100}
        person={{
          name: 'User Name 1',
          imageId: '12345',
        }}
      />
      <Avatar
        size={80}
        person={{
          name: 'User Name 2',
          imageId: '12346',
        }}
      />
      <Avatar
        size={50}
        person={{
          name: 'User Name 3',
          imageId: '12347',
        }}
      />
    </div>
  );
}

Пропсы позволяют вам думать о родительских и дочерних компонентах независимо друг от друга. Например, вы можете изменить пропсы person или size внутри Profile, не задумываясь о том, как Avatar их использует. Точно так же вы можете изменить то, как Avatar использует эти пропсы, не заглядывая в Profile. Вы можете думать о пропсах как о «ручках», которые вы можете регулировать. Они выполняют ту же роль, что и аргументы для функций — на самом деле пропсы являются единственным аргументом для вашего компонента. Функции компонента React принимают один аргумент, объект props:

function Avatar(props) {
  let person = props.person;
  let size = props.size;
  // ...
}

Обычно вам не нужен весь объект пропса, поэтому можно разбить его на отдельные пропсы. Не пропустите пару фигурных скобок { и } внутри ( и ) при объявлении пропсов:

function Avatar({ person, size }) {
  // ...
}

Этот синтаксис называется «деструктурированием» и эквивалентен чтению свойств из параметра функции:

function Avatar(props) {
  let person = props.person;
  let size = props.size;
  // ...
}

Как указать значения по умолчанию для пропса

Если вы хотите присвоить пропсу значение по умолчанию, чтобы использовать его, когда значение не указано, вы можете сделать это с помощью деструктуризации, поставив = и значение по умолчанию сразу после параметра:

function Avatar({ person, size = 100 }) {
  // ...
}

Теперь, если в <Avatar person={...} /> передан пропс size, размер будет установлен на 100. Значение по умолчанию используется только в том случае, если параметр size отсутствует или если вы передаете size={undefined}. Но если вы передадите size={null} или size={0}, значение по умолчанию не будет использоваться.

Перенаправление пропсов с синтаксисом распыления JSX

Иногда отправка пропсов повторяется:

function Profile({ person, size, isSepia, thickBorder }) {
  return (
    <div className="card">
      <Avatar
        person={person}
        size={size}
        isSepia={isSepia}
        thickBorder={thickBorder}
      />
    </div>
  );
}

В повторяющемся коде нет ничего плохого. Но иногда хочется сделать код короче. Некоторые компоненты передают все свои пропсы своим дочерним компонентам, например, как Profile делает с Avatar. Поскольку они не используют никакие свои пропсы напрямую, может иметь смысл использовать более краткий синтаксис распыления (spread):

function Profile(props) {
  return (
    <div className="card">
      <Avatar {...props} />
    </div>
  );
}

Это пример перенаправления всех пропсов Profile в Avatar без перечисления каждого из их имен. Используйте расширенный синтаксис с ограничениями. Если вы используете его в каждом компоненте - значит что-то не так. Часто это указывает на то, что следует разделить компоненты и передать дочерние компоненты как JSX. Подробнее об этом далее.

Передача JSX в качестве дочернего компонента

Обычно встроенные теги браузера вкладывают друг в друга:

<div>
  <img />
</div>

Иногда вы захотите вложить свои собственные компоненты таким же образом:

<Card>
  <Avatar />
</Card>

Когда вы вкладываете контент в тег JSX, родительский компонент получит этот контент в просе, называемом children. Например, компонент Card ниже получит проп children, который является <Avatar />, и отобразит его в обертке div:

// App.js

import Avatar from './Avatar.js';

function Card({ children }) {
  return <div className="card">{children}</div>;
}

export default function Profile() {
  return (
    <Card>
      <Avatar
        size={100}
        person={{
          name: 'User Name',
          imageId: '12345',
        }}
      />
    </Card>
  );
}

// Avatar.jsx

import { getImageUrl } from './utils.js';

export default function Avatar({ person, size }) {
  return (
    <img
      className="avatar"
      src={getImageUrl(person)}
      alt={person.name}
      width={size}
      height={size}
    />
  );
}

// utils.js

export function getImageUrl(person, size = 's') {
  return 'https://example.com/' + person.imageId + size + '.jpg';
}

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

Как пропсы меняются со временем

Компонент Clock ниже получает два пропса от своего родительского компонента: color и time. (Код родительского компонента опущен, поскольку он использует состояние, в которое мы пока не будем углубляться.)

export default function Clock({ color, time }) {
  return <h1 style={{ color: color }}>{time}</h1>;
}

Этот пример иллюстрирует, что компонент может получать пропсы с течением времени. Проп не всегда статичен. Здесь проп time меняется каждую секунду, а проп color меняется, когда вы выбираете другой цвет. Пропсы отражают данные компонента в любой момент времени, а не только в начале. Пропсы иммутабельны — термин из информатики, означающий «неизменяемый». Когда компоненту необходимо изменить свои пропсы (например, в ответ на взаимодействие с пользователем или новые данные), ему придется «попросить» родительский компонент передать ему другие пропсы — новый объект. Затем его старые пропсы будут отброшены, и в конечном итоге движок JavaScript очистит занятую ими память. Не пытайтесь "изменить пропсы" напрямую. Когда вам нужно отреагировать на пользовательский ввод (например, изменить выбранный цвет), вам нужно будет "установить состояние", о котором вы можете узнать в разделе "Состояние - память компонента".

Резюме

Чтобы передать пропсы, добавьте их в JSX, как и в случае с атрибутами HTML.
Чтобы прочитать пропсы, используйте синтаксис деструктурирования function Avatar({ person, size }).
Вы можете указать значение по умолчанию, например size = 100, которое используется для отсутствующих и неопределенных пропсов.
Вы можете перенаправить все пропсы с помощью синтаксиса распыления JSX <Avatar {...props} />, но не злоупотребляйте им.
Вложенный JSX, такой как <Card><Avatar /></Card>, будет отображаться как проп children компонента Card.
Пропсы - доступны только для чтения. Это такой снимок компонента во времени: каждый рендер получает новую версию пропса.
Нельзя менять пропсы внутри компонента. Когда вам нужна интерактивность, вам нужно установить состояние.

Frontend React Туториал по React

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

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

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

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

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

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

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

Шаг 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 для вас.

Frontend JavaScript Webpack Микрофронтенд