Вопросы и ответы React собеседования 2023 - Часть 2

• Вопросы и ответы ReactJS собеседования 2023 - Часть 1
• Вопросы и ответы ReactJS собеседования 2023 - Часть 2 (эта статья)
• Вопросы и ответы ReactJS собеседования 2023 - Часть 3

1. Что такое JSX?

• JSX — это расширение синтаксиса для JavaScript, обладающее всеми возможностями JavaScript.
• Вы можете внедрить любое выражение JavaScript в JSX, заключив его в фигурные скобки. После компиляции выражения JSX становятся обычными объектами JavaScript.
• Это означает, что вы можете использовать JSX внутри операторов if и циклов for, назначать его переменным, принимать в качестве аргументов и возвращать из функций.

2. Каков эквивалент следующего кода с использованием React.createElement?

const element = <h1 className="greeting">Hello, world!</h1>;

Эквивалент с использованием React.createElement будет выглядеть следующим образом:

const element = React.createElement(
  "h1",
  { className: "greeting" },
  "Hello, world!"
);

3. Что такое Redux?

• Основная идея redux заключается в том, что все состояние приложения хранится в одном хранилище. Store (хранилище) - это просто JavaScript объект.
• Единственный способ изменить состояние — отправить действие (action) из вашего приложения, а затем написать редьюсеры для этих действий, которые изменяют состояние.
• Весь переход состояния хранится внутри редьюсеров и не должен иметь никаких побочных эффектов.

Подробнее о Redux можно узнать в бесплатном видео-курсе о Redux.

4. Что такое store в Redux?

Store — это JavaScript объект, который содержит состояние приложения. Наряду с этим он также имеет следующие обязанности:

• Разрешает доступ к состоянию через getState().
• Позволяет обновлять состояние с помощью отправки действия dispatch(action).
• Регистрирует слушателей через subscribe(listener).
• Обрабатывает отмену регистрации слушателей с помощью функции, возвращаемой из subscribe(listener).

5. Разница между action и reducer.

• Action (действие) — это простые JavaScript объекты.
• Они должны иметь тип, указывающий тип выполняемого действия.
• По сути, действия — это некоторые данные, которые отправляются из вашего приложения в хранилище.
• Редьюсер — это просто чистая функция, которая принимает предыдущее состояние и действие и возвращает обновленное состояние.

6. Для чего используется Redux Thunk?

• Redux Thunk — это промежуточное программное обеспечение (middleware), которое позволяет вам писать создателей действий (action creator), которые возвращают функцию вместо действия (action). Что такое action creators?
• Затем thunk можно использовать для задержки отправки действия, если выполняется определенное условие. Это позволяет вам обрабатывать асинхронную диспетчеризацию действий.
• Подробнее о Redux Thunk можно узнать в полном видео-курсе о Redux Thunk.

7. Напишите кастомный хук, который можно использовать для debounce’а ввода.

// Хук useDebounce

const useDebounce = (value, delay) => {
  const [debouncedValue, setDebouncedValue] = useState(value);

  useEffect(() => {
    const timeout = setTimeout(() => {
      setDebouncedValue(value);
    }, delay);

    return () => {
      clearTimeout(timeout);
    };
  }, [value]);

  return debouncedValue;
};

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

const Counter = () => {
  const [value, setValue] = useState(0);
  const lastValue = useDebounce(value, 1000);

  return (
    <div>
      <p>
        Current Value: {value} | Debounced Value: {lastValue}
      </p>
      <button onClick={() => setValue(value + 1)}>Increment</button>
    </div>
  );
};

8. Напишите кастомный хук для копирования текста в буфер обмена.

// Хук useCopyToClipboard

function useCopyToClipboard(content) {
  const [isCopied, setIsCopied] = useState(false);

  const copy = useCallback(() => {
    navigator.clipboard
      .writeText(content)
      .then(() => setIsCopied(true))
      .then(() => setTimeout(() => setIsCopied(false), 1250))
      .catch((err) => alert(err));
  }, [content]);
  return [isCopied, copy];
}

// Использование
export default function App() {
  const [isCopied, copy] = useCopyToClipboard("Text to copy!");
  return <button onClick={copy}>{isCopied ? "Copied!" : "Copy"}</button>;
}

9. Как использовать хук useId для создания уникальных идентификаторов?

• useId не принимает никаких параметров.
• useId возвращает уникальную строку идентификатора, связанную с этим конкретным вызовом useId в этом конкретном компоненте.

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

import { useId } from "react";

const App = () => {
  const id = useId();

  return (
    <form>
      <label htmlFor={`email-${id}`}>Email</label>
      <input type="text" id={`email-${id}`} name="email" />

      <label htmlFor={`password-${id}`}>Password</label>
      <input type="password" id={`password-${id}`} name="password" />
    </form>
  );
};

// Плохая практика - не стоит использовать в качестве key
const id = useId();

return posts.map((post) => <article key={id}>...</article>);

Подробности можно найти в статье Что за хук useId в React?.

10. Как проверить/валидировать пропсы в React?

Мы можем использовать пакет prop-types Раньше, до React v15.5, это было частью самого React.

import PropTypes from "prop-types";

function MyComponent({ name }) {
  return <div>Hello, {name}</div>;
}

MyComponent.propTypes = {
  name: PropTypes.string,
};

export default MyComponent;

Еще один вариант - это добавить к проекту TypeScript.

11. Приведите практический пример компонента высшего порядка в React.

• Напишем компонент высшего порядка (HOC) для отображения загрузки, пока компонент ожидает данные.
• Больше о компонентах высшего порядка можно узнать в видео Как использовать Компоненты высшего порядка React и Паттерн Render Props в ReactJS.

// Компонент высшего порядка
function WithLoading(Component) {
  return function WihLoadingComponent({ isLoading, ...props }) {
    if (!isLoading) return <Component {...props} />;
    return <p>Please wait, fetching your data in no time...</p>;
  };
}
export default WithLoading;

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

import UserListComponent from "./UserListComponent.js"; // импорт компонента
import WithLoading from "./withLoading.js"; // импорт HOC

const ListWithLoading = WithLoading(UserListComponent); // обернем компонент в HOC

const App = () => {
  const [loading, setLoading] = useState(true);
  const [users, setUsers] = useState([]);

  useEffect(() => {
    // запрос данных
    const dataFromApi = ["this is coming from API call", "don't show loader"];
    
    // в это время загрузчик будет показан в HOC
    // данные получены
    setUsers([...dataFromApi]);
    setLoading(false);
  }, []);

  return <ListWithLoading isLoading={loading} users={users} />;
};

12. Чем полезен хук useDeferredValue?

• useDeferredValue — это React хук, который позволяет вам отложить обновление части пользовательского интерфейса.
• По сути, это позволяет вам выполнять технику debounce с меньшим количеством кода.
• Подробный разбор хука useDeferredValue можно прочитать в статье Хуки useTransition и useDeferredValue в ReactJS 18.

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

import { useState, useDeferredValue } from "react";
// Компонент userList получает searchText для запроса списка пользователей
import UserList from "./UserList.js";

export default function App() {
  const [searchText, setSearchText] = useState("");
  // отправить searchText по умолчанию
  const deferredQuery = useDeferredValue(searchText);

  return (
    <>
      <label>
        Search user:
        <input
          value={searchText}
          onChange={(e) => setSearchText(e.target.value)}
        />
      </label>
      <div>
        <UserList searchText={deferredQuery} />
      </div>
    </>
  );
}

13. Как отследить клик за пределами компонента React?

export default function OutsideAlerter() {
  const clickMeDivRef = useRef(null);

  useEffect(() => {
    const handleClickOutside = (event) => {
      if (!ref?.current?.contains(event.target)) {
        alert("You clicked outside of me!");
      }
    };

    // Добавим прослушивание событий
    document.addEventListener("mousedown", handleClickOutside);

    return () => {
      // Удалим прослушивание событий
      document.removeEventListener("mousedown", handleClickOutside);
    };
  }, [clickMeDivRef]);

  return <div ref={clickMeDivRef}>Clicked me?</div>;
}

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

В JSX имена тегов нижнего регистра считаются тегами HTML. Однако имена тегов в нижнем регистре с точкой (аксессор свойства) не являются таковыми.

• <person /> компилируется в React.createElement('person') (тег html)
• компилируется в React.createElement(Person)
• <obj.person /> компилируется в React.createElement(obj.person)

// Ошибка! Это компонент и должен начинаться с заглавной буквы
function person(props) {
  // Верно! Это использование <div> верно, т.к. div это валидный элемент
  return <div>{props.isLearning ? "Great!" : "Hello!"}</div>;
}

function App() {
  // Ошибка! React считает <person /> тэгом HTML, т.к. Не с заглавной буквы
  return <person isLearning={true} />;
}

// Верно! Это компонент и должен начинаться с заглавной буквы
function Person(props) {
  // Верно! Это использование <div> верно, т.к. div это валидный элемент
  return <div>{props.isLearning ? "Great!" : "Hello!"}</div>;
}

function App() {
  // Верно! React знает, что <Person /> - это компонент, с заглавной буквы
  return <Person isLearning={true} />;
}

15. В чем разница между npx и npm?

• npm — это менеджер пакетов, который можно использовать для установки пакетов node.js. npM - Manager.
• npx— это инструмент для выполнения пакетов node.js. npX - Execute.

Неважно, установили ли вы этот пакет глобально или локально. npx временно установит его и запустит. npm также может запускать пакеты, если вы настроите файл package.json. Поэтому, если вы хотите быстро проверить/запустить пакет без его установки - используйте npx. create-react-app — это npm пакет, который должен запускаться только один раз в жизненном цикле проекта. Следовательно, предпочтительнее использовать npx для установки и запуска за один шаг.

> npx create-react-app my-app

16. Как установить фокус на поле ввода после монтирования компонента в UI?

import React, { useEffect, useRef } from "react";

const SearchPage = () => {
  const textInput = useRef(null);

  useEffect(() => {
    textInput.current.focus();
  }, []);

  return (
    <div>
      <input ref={textInput} type="text" />
    </div>
  );
};

Еще больше вопросов с собеседований

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

• Структура React приложения
• Архитектура современного React приложения

В этой статье мы подробно рассмотрим работу с бизнес-логикой. Во многих случаях разработчики пишут бизнес логику прямо в компонентах. Даже опытные разработчики ограничиваются вынесением этих вычислений в кастомные хуки или какие-либо вспомогательные функции. Но все еще это оставляет проблему нерешенной. Дело в том, что даже если у нас есть более мелкие компоненты и логика перемещена в хуки или хэлперы, они буквально разбросаны повсюду неорганизованно. Возьмем, к примеру, приложение онлайн магазина, если мы хотим изменить логику в cart, скорее всего, нам также придется изменить модули product и validation. И нам обычно приходится менять как хэлперы, так и представления (не говоря уже о связанных с ними тестах).

Как обстоят дела в React

Рассмотрим проблему на более высоком уровне. Если вы внимательно посмотрите на React и согласитесь, что он отвечает только за визуальную часть нашего приложения, многие проблемы будут решены автоматически. Независимо от того, используем ли мы традиционные шаблоны MVC/MVP или их вариант MVVM, если React — это V, очевидно, нам нужно что-то еще, чтобы заполнить роль M или VM в приложении. Среди многих проектов я также обнаружил, что многие хорошие практики, которые мы используем в бэкенде, не признаны в мире фронтенда, такие как слоеная структура, паттерны проектирования и т. д. Одна из возможных причин заключается в том, что фронтенд относительно молодой и ему нужно некоторое время, чтобы наверстать упущенное. Например, в типичном приложении Spring MVC у нас были бы controller, service и repository, и каждый разработчик принимает причину такого разделения: controller не содержит бизнес-логики, service не знает, как модель отображается или сериализуется для пользователей, а repository работает только о доступом к данным. Однако во фронтенд-приложениях на React из-за отсутствия встроенной поддержки (например, отсутствия контроллеров или слоя репозитория) мы вместо этого пишем этот код в компоненты. И это приведет к тому, что бизнес-логика будет повсюду. Итерации станут медленными, а качество кода низким.

Утечка бизнес-логики

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

• Использование преобразователей данных
• x.y.z
• Защитное программирование

Использование преобразователей данных

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

fetch(`https://example.com/api/addresses`)
.then((r) => r.json())
.then((data) => {
    const addresses = data.map((item: RemoteAddress) => ({
        street: item.streetName,
        address: item.streetAddress,
        postcode: item.postCode
    }))
    setAddresses(addresses)
});

В приведенном выше фрагменте то, что возвращает бэкэнд, не совсем соответствует тому, что потребляет UI, поэтому нам нужно преобразовать полученные данные. Мы можем использовать сервис, разработанный другой командой, или использовать сторонний сервис (например, Google Search API). Таким образом, казалось бы, безобидный код нарушил здесь несколько принципов:

• Компонент должен знать тип RemoteAddress
• Компоненту необходимо определить новый тип Address (setAddresses)
• data.map выполняет низкоуровневое сопоставление

Симптом x.y.z (нарушение закона Деметры)

Если вы используете более одного оператора точки ., вероятно, это означает, что отсутствуют некоторые концепции. person.deliveryAddress лучше, чем person.primaryAddress.street.streetNumber + person.primaryAddress.suburb так как первый вариант правильно скрывает детали. Приведенный ниже код показывает, что ProductDialog слишком много знает о product, и как только структура product изменится, нам придется менять множество мест (тесты и компоненты)

const ProductDialog = (props) => {
  const { product } = props;
  if(product.item.type === 'Portion') {
    //do something
  }
}

Здесь мы имеем дело с данными, а не с моделью. Таким образом, product.isPortion() будет более значимым, чем проверка необработанных данных.

Защитное программирование

Во многих проектах люди склонны делать слишком много в компоненте, и это создает много шума в коде. Например:

const ProductDetails = (props) => {
  const { product } = props
  const { item } = product
  const { media } = item as MenuItem
  
  const title = (media && media.name) || ''
  const description = (media && media.description) || ''
  return (
    <div>
      {/* product details */}
    </div>
  )
}

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

Как решить проблему?

На практике мы можем попробовать двухэтапный подход к решению проблемы.

1. Регулярный рефакторинг
2. Создание моделей

Регулярный рефакторинг

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

• Использования преобразователей данных
• x.y.z
• Защитного программирования

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

const transformAddress: Address = (address: RemoteAddress) => {
    return ({
        street: datum.streetName,
        address: datum.streetAddress,
        postcode: datum.postCode
    })
}
//...
const addresses = data.map(transformAddress)

Также иногда бывает нужно преобразовать аббревиатуры в текст такие как VIC или NSW, но нам нужно показать их в полном тексте на странице как Victoria или New South Wales.

const states = {
  vic: "Victoria",
  nsw: "New South Wales",
  //...
};

const transformAddress: Address = (address: RemoteAddress) => {
  return {
    street: address.streetName,
    address: address.streetAddress,
    postcode: address.postCode,
    state: states[address.state.toLowerCase()]
  };
};

Точно так же мы можем использовать функцию, для проверки title и description и вывода запасного значения:

const getTitle = (media) => (media && media.name) || ''
const getDescription = (media) => (media && media.description) || ''

По мере добавления все больше и больше логики, такой transformAddress и getTitle, они будут перемещаться в helpers.ts, в конечном итоге у нас будет огромный файл. Это означает, что он станет нечитаемым и будет иметь высокие затраты на обслуживание. Мы можем разделить файл на модули, но связи между этими функциями могут затруднить их понимание. Это похоже на проблему, с которой мы сталкивались до объектно-ориентированного программирования - у нас слишком много модулей и функций в каждом модуле, и слишком сложно ориентироваться в них. Другими словами, нам нужен лучший способ организации этих вспомогательных функций. К счастью, нам не нужно изобретать велосипеды. Нам может помочь объектно-ориентированное программирование. Просто используя классы и инкапсуляцию в ООП, мы можем легко сгруппировать эти функции и сделать код намного более читабельным. Чтобы сгруппировать код создадим модели.

Создание моделей

Короче говоря, создание моделей — это объединение данных и поведения, сокрытие деталей и обеспечение общего API для потребителей. Например, мы не должны использовать product.item.type === 'Portion', вместо этого мы должны создать класс Product, и у него есть isPortion для их потребителей. Это очень распространено в бэкенд-сервисах, но не получило широкого распространения в мире фронтенда. Причина в том, что, как упоминалось выше, люди упускают из виду, что React отвечает только за визуализацию. И здоровое фронтенд-приложение должно иметь и другие части. Ему нужны модели и логика для взаимодействия с серверной частью, даже для ведения логирования. Возвращаясь к приведенному выше примеру, определив класс Address для замены анонимной функции внутри data.map, мы получим:

class Address {
  constructor(private addr: RemoteAddress) {}
  get street() {
    return this.addr.streetAddress;
  }
  get postcode() {
    return this.addr.postcode;
  }
}

Нет никакой разницы в использовании:

const AddressLine = ({ address }: { address: Address }) => (
  <li>
    <div className="result">{address.street}</div>
  </li>
);

Единственное, что нужно изменить, это заменить transformAddress на new Address:

const addresses = data.map((addr: RemoteAddress) => new Address(addr))

И для частного члена/функции для перевода названия штата:

private readonly states = {
  vic: "Victoria",
  nsw: "New South Wales",
  //...
};

get state() {
  return this.states[this.addr.state.toLowerCase()];
}

Структура теперь намного точнее. states теперь является приватным членом класса Address. Класс хорош тем, что он объединяет всю связанную логику в одну часть, что делает его изолированным и простым в обслуживании. Размещение всей связанной логики в одном месте имеет и другие преимущества. Во-первых, такое разделение делает тестирование простым и надежным, поскольку компоненты зависят от модели (а не от исходных данных). Нам не нужно готовить данные с нулевым значением или значения вне границ предусмотренных значений для тестов компонентов. Точно так же модель тестирования больше фокусируется на данных и логике (пустое значение, проверка и запасное значение). Во-вторых, согласованность повышает вероятность его повторного использования в других сценариях. Наконец, если нам нужно переключиться на другую стороннюю службу, нам нужно только изменить модели, и представления могут остаться нетронутыми. По мере того, как создается все больше и больше моделей, нам может понадобиться целый слой для них. Эта часть кода не знает о существовании компонентов пользовательского интерфейса и связана исключительно с бизнес-логикой.

Итоги

Инкапсуляция бизнес-логики, даже в контексте тонких клиентов, является относительно большой темой. В этой статье мы рассмотрели несколько симптомов утечки бизнес-логики и то, как с ними бороться. Проводя регулярный рефакторинг, мы можем гарантировать, что компоненты отвечают только за рендеринг данных и не должны выполнять какие-либо вычисления или сопоставление данных. Мы должны разделить эту логику на чистые файлы JavaScript (а не jsx/tsx). И с помощью создания моделей мы можем использовать объекты только для того, чтобы скрыть детали доступа к данным. Преимущества этого подхода заключаются в том, что тестирование как модели, так и представлений значительно упрощается, легче отслеживать изменения бизнес-требований и гораздо более простой код в представлениях (поскольку большая часть этого делается в моделях).