Одна из причин за что НЕ любят Redux

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

Зачем вообще нужно глобальное хранилище? Действительно ли наши веб-приложения настолько сложны, или мы пытаемся их переусложнить, используя Redux?

Redux был революционной технологией в экосистеме React. Это позволило нам иметь глобальное хранилище и устранило проблему prop drilling в нашем дереве компонентов. Для совместного использования иммутабельных данных в приложении он по-прежнему остается отличным инструментом, который очень хорошо масштабируется.

Проблема одностраничных приложений

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

Redux - это не кэш

Основная проблема, с которой сталкивается большинство из нас при использовании Redux и подобных библиотек управления состоянием, заключается в том, что мы рассматриваем его как кэш для нашего внутреннего состояния. Мы извлекаем данные, добавляем их в наше хранилище с помощью редьюсера/экшена и периодически обновляем их, чтобы убедиться, что они актуальны. Мы заставляем Redux делать слишком много и используем его как универсальное решение наших проблем. Одна важная вещь, которую следует помнить, это то, что данные на фронтенде и на бэкэнде никогда не синхронизированы по настоящему, это лишь иллюзия. Это один из недостатков модели клиент-сервер, и именно поэтому нам нужен кэш. Однако кэширование и синхронизация состояния чрезвычайно сложны, поэтому мы не должны воссоздавать это состояние бэкэнда с нуля.
Граница между ответственностью бэкэнда и фротенда быстро стирается, когда мы начинаем воссоздавать базу данных на фротенде . Как фротенд-разработчикам, нам не нужно досконально разбираться в таблицах и их связях, чтобы создать простой пользовательский интерфейс. Нам также не нужно знать, как лучше всего нормализовать наши данные. Эта ответственность должна лежать на людях, которые сами проектируют таблицы — на бэкэнд-разработчиках. Бэкенд-разработчики затем могут предоставить абстракцию для фронтенд-разработчиков в виде документированного API. В настоящее время существует множество библиотек (redux-observable, redux-saga и redux-thunk, и это лишь некоторые из них), построенных вокруг Redux, чтобы помочь нам управлять данными из бэкэнда, каждая из которых добавляет уровень сложности к уже и так сложной для инициализации библиотеке. Иногда нам нужно сделать шаг назад, прежде чем сделать шаг вперед.

Более простой подход к хранению данных с бэкэнда

Есть пара библиотек, которые обладают преимуществами перед Redux (или аналогичной библиотекой управления состоянием) для хранения состояния бэкэнда.

React Query

Это библиотека с очень простым API и парой хуков для управления запросами (выборка данных) и мутациями (изменение данных). Благодаря использованию React Query удается писать гораздо меньше шаблонного кода, чем с Redux. Становится проще сосредоточиться на UI/UX веб-приложения, не заботясь о проблемах поддержки состояния бэкэнда.
Чтобы сравнить эту библиотеку с Redux, рассмотрим пример двух методов. Для примера используем простой список TODO, полученный с сервера. Реализация с Redux.
import React, { useEffect } from "react";
import { useSelector, useDispatch } from "react-redux";
import axios from 'axios';

const SET_TODOS = "SET_TODOS";

export const rootReducer = (state = { todos: [] }, action) => {
  switch (action.type) {
    case SET_TODOS:
      return { ...state, todos: action.payload };
    default:
      return state;
  }
};

export const App = () => {
  const todos = useSelector((state) => state.todos);
  const dispatch = useDispatch();

  useEffect(() => {
    const fetchPosts = async () => {
      const { data } = await axios.get("/api/todos");
      dispatch({
        type: SET_TODOS,
        payload: data
      });
    };

    fetchPosts();
  }, []);

  return (
    <ul>{todos.length > 0 && todos.map((todo) => <li>{todo.text}</li>)}</ul>
  );
};
Обратите внимание, что в этом коде еще даже нет повторной выборки данных, кэширования и инвалидации кэша. Это просто загрузка данные и сохранение их в глобальное хранилище. Вот тот же пример, реализованный с помощью React Query.
import React from "react";
import { useQuery } from "react-query";
import axios from "axios";

const fetchTodos = async () => {
  const { data } = await axios.get("/api/todos");
  return data;
};

const App = () => {
  const { data } = useQuery("todos", fetchTodos);

  return data ? (
    <ul>{data.length > 0 && data.map((todo) => <li>{todo.text}</li>)}</ul>
  ) : null;
};
По умолчанию код с React Query уже включают повторную выборку данных, кэширование и инвалидацию устаревших данных с предустановленной конфигурацией. Можно также установить конфигурацию кэширования на глобальном уровне. Везде, где вам нужны эти данные, теперь вы можете использовать хук useQuery с уникальным ключом, который вы установили (в данном случае todos), и асинхронным вызовом для получения данных. Пока функция асинхронная, реализация не имеет значения — вы можете так же легко использовать Fetch API вместо Axios. Для изменения внутреннего состояния React Query предоставляет хук useMutation.

SWR

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

Apollo Client

SWR и React Query ориентированы на REST API, но если вам нужно что-то подобное для GraphQL, то явным претендентом является Apollo Client. Также приятно, что синтаксис почти идентичен React Query.

Встроенные возможности для работы с состоянием

Как только вы начнете использовать одну из этих библиотек, вы обнаружите, что в подавляющем большинстве проектов Redux является излишним. Когда не придется самим заниматься запросом и кешированием данных в веб-приложении, на фронтенде останется лишь небольшая часть глобального состояния. То немногое, что осталось, можно обработать с помощью Context API или useContext + useReducer, чтобы создать свой собственный псевдо-Redux. Или, что еще лучше, для простых кейсов можно использовать встроенное состояние React.
// чисто, красиво и просто
const [состояние, setState] = useState();

Вопросы по React на собеседовании

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

В‌ ‌этой ‌статье рассмотрим вопросы, которые могут встретиться на собеседовании по ReactJS на позицию React или frontend разработчика в 2023 году.

Что нового появилось в React 18?

1. Автоматический батчинг setState

В React 17 только React события будут обрабатываться пакетно, а нативные JavaScript события, промисы, setTimeout и setInterval обрабатываться не будут. В React 18 все события обрабатываются пакетно, т.е. несколько setState будут объединены в одно выполнение, что повышает производительность. На уровне данных несколько обновлений состояния объединяются в одну обработку (на уровне представления несколько визуализаций объединяются в одну визуализацию).

2. Новый root API

В React 18 представлен новый root API, который поддерживает новый конкурентный рендеринг.
// React 17
import React from "react"
import ReactDOM from "react-dom"
import App from "./App"

const root = document.getElementById("root")
ReactDOM.render(root, <App />)

// unmount the component
ReactDOM.unmountComponentAtNode(root) 

// React 18
import React from "react"
import ReactDOM from "react-dom/client"
import App from "./App"

const root =  document.getElementById("root")
ReactDOM.createRoot(root).render(<App />)

// unmount the component
root.unmount()

3. Прекращение поддержки IE

Удалена поддержка браузера IE. Все новые функции, представленные React 18, основаны на современных браузерах. Если вам нужна поддержка IE, вам нужно вернуться к версии React 17.

4. flushSync

Используется, чтобы заставить React сбросить всю ожидающую работу и синхронно обновить DOM.
import React, {useState} from "react"
import {flushSync} from "react-dom"

const  App = () => {
  const [count, setCount] = useState(0)
  const [count2, setCount2] = useState(0)

  return (
    <div className="App">
      <button onClick={() => {
        // первое обновление
        flushSync(() => {
          setCount(count => count + 1)
        })
        // второе обновление
        flushSync(() => {
          setCount2(count2 => count2 + 1)
        })
      }}>click</ button >
       
      <span>count: {count}</ span >
      <span>count2: {count2}</ span >	
     </div>	
  )
}

export default App

5. Возвращаемое значение React компонента

В React 17 для возврата пустого компонента можно использовать только null, а явное возвращение undefined вызовет ошибку. В React 18 поддерживается возврат null и undefined.

6. Поддержка useId

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

7. Concurrent mode (Конкурентный режим)

Конкурентный режим — это не фича, а архитектура. Это помогает приложениям оставаться отзывчивыми, подстраиваясь под производительность устройства пользователя и скорость сети, а также устраняет блокировку механизмов рендеринга, делая рендеринг прерываемым. В React несколько состояний могут быть обновлены одновременно. Разница в том, чтобы синхронные непрерываемые обновления стали асинхронными прерываемыми обновлениями. useDeferredValue и startTransition используются для обозначения несрочного обновления.

Почему React компоненты не могут возвращать несколько элементов?

Почему компоненты React могут иметь только один корневой элемент?
  1. Компонент React в конце будет скомпилирован в функцию рендеринга, и возвращаемое значение функции может быть только одно. Если он не обернут в отдельный корневой узел, несколько значений будут возвращаться параллельно, что не допускается в JavaScript.
class App extends React.Component{
  render() {
    return(
      <div>
        <h1 className="title">Hello</h1>
        <span>World</span>	
      </div>	
    )
}

// После компиляции
class App extends React.Component {
  render() {
    return React.createElement('div', null,
      [
        React.createElement('h1', {className:'title'}, 'Hello'),
        React.createElement('span', null, 'World')
      ]
    )
  }
}
  1. Виртуальный DOM React представляет собой древовидную структуру, и корневой узел дерева может быть только один. При наличии нескольких корневых узлов невозможно подтвердить, какое дерево нужно обновить.

Как компоненты React могут возвращать несколько компонентов?

  • Используя HOC (Higher Order Functions)
  • Используя React.Fragment, вы можете добавить список элементов в группу, не создавая дополнительных узлов.
renderList() {
  list.map((item, key) => {
    return (
      <React.Fragment>
        <tr key={item.id}>
          <td>{item.name}</td>
          <td>{item.age}</td>
          <td>{item.address}</td>
        </tr>	
      </React.Fragment>
    )
  })
}
  • Используя массив
renderList(){
  list.map((item, key) => {
    return [
      <tr key={item.id}>
        <td>{item.name}</td>
        <td>{item.age}</td>
        <td>{item.address}</td>
      </tr>
    ]
  })
}

Каковы способы общения между React компонентами?

Существует множество способов взаимодействия компонентов, которые можно разделить на следующие категории:
  • Взаимодействие родительского компонента с дочерним компонентом
  • Дочерний компонент взаимодействует с родительским компонентом
  • Общение между соседними элементами
  • Родительский компонент взаимодействует с дочерними компонентами
  • Связь независимых компонентов
Подробнее о каждой категории можно прочитать в этой статье.
Также по теме собеседований рекомендую прочитать: