[Перевод] Как управлять состоянием React приложения без сторонних библиотек22.06.2020 04:47

function Counter() {
  const [count, setCount] = React.useState(0)
  const increment = () => setCount(c => c + 1)
  return 

Имейте в виду что все, о чем здесь идет речь, работает и с классами. Хуки просто упрощают работу (особенно работу с контекстом, вскоре мы рассмотрим и такой вариант).

class Counter extends React.Component {
  state = {count: 0}
  increment = () => this.setState(({count}) => ({count: count + 1}))
  render() {
    return {this.state.count}
  }
}

«Окей, это конечно легко — управлять одним элементом состояния в одном компоненте, но что если мне нужно разделить это состояние между компонентами? Например, что, если я хочу сделать это:

function CountDisplay() {
  // откуда нам брать значение для `count`?
  return 
The current counter count is {count}
}

function App() {
  return (
    

      
      
    
  )
}

«Управление состоянием для подсчета значения происходит внутри , выходи, теперь мне нужна библиотека управления состоянием, чтобы получить доступ к значению count для  и для его обновлений в !»

Ответ этот вопрос настолько же стар, настолько стар и сам Реакт (или старше?), и был в документации столько, сколько я себя помню: Подъём состояния

Подъём состояния (Lifting State Up) это надежный и рекомендуемый способ управления состоянием в Реакте. Вот каким образом можно применять его:

function Counter({count, onIncrementClick}) {
  return {count}
}

function CountDisplay({count}) {
  return 
The current counter count is {count}
}

function App() {
  const [count, setCount] = React.useState(0)
  const increment = () => setCount(c => c + 1)
  return (
    

      
      
    
  )
}

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

«Да, конечно, но что на счет проблемы проп дриллинга (prop drilling)?»

На самом деле это проблема у которой уже довольно давно есть решение — контексты (context). На протяжении долгого времени люди применяли react-redux из-за предупреждений в документации Реакта об использовании контекстов. Но сейчас контексты это официально поддерживаемая часть React API, и мы можем использовать их напрямую:

// src/count/count-context.js
import React from 'react'

const CountContext = React.createContext()

function useCount() {
  const context = React.useContext(CountContext)
  if (!context) {
    throw new Error(`useCount must be used within a CountProvider`)
  }
  return context
}

function CountProvider(props) {
  const [count, setCount] = React.useState(0)
  const value = React.useMemo(() => [count, setCount], [count])
  return 
}

export {CountProvider, useCount}

// src/count/page.js
import React from 'react'
import {CountProvider, useCount} from './count-context'

function Counter() {
  const [count, setCount] = useCount()
  const increment = () => setCount(c => c + 1)
  return {count}
}

function CountDisplay() {
  const [count] = useCount()
  return 
The current counter count is {count}
}

function CountPage() {
  return (
    

      
        
        
      
    
  )
}

ПРИМЕЧАНИЕ. Этот код является просто примером, и я НЕ рекомендую использовать контекст для решения конкретно этой проблемы. В данном случае более простым решением стало бы просто передача состояний через пропсы (подробнее здесь: Prop Drilling). Не нужно применять контексты там где можно обойтись более простыми методами.

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

function useCount() {
  const context = React.useContext(CountContext)
  if (!context) {
    throw new Error(`useCount must be used within a CountProvider`)
  }
  const [count, setCount] = context

  const increment = () => setCount(c => c + 1)
  return {
    count,
    setCount,
    increment,
  }
}

При желании можно поменять useState на useReducer:

function countReducer(state, action) {
  switch (action.type) {
    case 'INCREMENT': {
      return {count: state.count + 1}
    }
    default: {
      throw new Error(`Unsupported action type: ${action.type}`)
    }
  }
}

function CountProvider(props) {
  const [state, dispatch] = React.useReducer(countReducer, {count: 0})
  const value = React.useMemo(() => [state, dispatch], [state])
  return 
}

function useCount() {
  const context = React.useContext(CountContext)
  if (!context) {
    throw new Error(`useCount must be used within a CountProvider`)
  }
  const [state, dispatch] = context
  const increment = () => dispatch({type: 'INCREMENT'})
  return {
    state,
    dispatch,
    increment,
  }
}

Это дает нам гибкость и уменьшает сложность кода. Вот о чем следует помнить когда вы так делаете:

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

   
   

2. Не нужно делать все контексты глобальными! Держите состояние как можно ближе к месту к которому оно относиться.

   
   

Подробнее о втором пункте. Структура вашего приложения может выглядеть примерно так:

function App() {
  return (
    
      
        
          
          
          
          
          
        
      
    
  )
}

function Notifications() {
  return (
    
      
      
      
    
  )
}

function UserPage({username}) {
  return (
    
      
      
      
    
  )
}

function UserSettings() {
  // это специальный кастомный хук для AuthenticationProvider
  const {user} = useAuthenticatedUser()
}

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

Если хотите узнать больше о том что такое «совместное размещение», читайте статью State Colocation will make your React app faster (на русском как сделать React приложение быстрее при помощи совместного размещения состояний
) и Colocation. А если интересно почитать больше о работе с контекстами, читайте статью How to use React Context effectively

Кэш Сервера против Состояние Интерфейса

Существуют различные виды состояний приложения, но каждый тип состояния можно отнести к одной из этих категорий:

1. Кэш Сервера (Server Cache) — состояние которое размещено на сервере для быстрого доступа к нему на клиенте (к примеру — данные пользователя).

   
   

2. Состояние Интерфейса (UI State) — состояние в котором есть смысл только в интерфейсе пользователя, оно нужно для управления интерактивными частями приложения (к примеру, открытие модального окна — modal isOpen)

   
   

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

Вы определенно можете управлять им при помощи ваших собственных useState или useReducer, с правильными useContext там и тут. Но, имейте в виду, кэширование это очень сложная проблема (некоторые говорят что это одна из сложнейших проблем в информатике), так что, касательно этого вопроса, будет разумно «встать на плечи гигантов».

Я сам использую, и всячески рекомендую библиотеку react-query для подобных состояний. Знаю, знаю, я сам сказал что вам не нужны библиотеки для управления состоянием, но, я не считаю что react-query это библиотека для управления состоянием. Я считаю что это библиотека для управления кэшем. И она офигенно хороша. Попробуйте ее. Этот парень — Tanner Linsley весьма умен.

Заключение

Как я уже говорил, все это вы можете реализовать применяя классовые компоненты (вам не обязательно использовать хуки). Хуки просто делают все намного проще, но вы можете реализовать эту философию и в React 15. Опускайте состояние как можно ниже по иерархии компонентов, и используйте контекст только тогда когда проп дриллинг реально станет проблемой. Все эти действия помогут вам упростить работу с состоянием вашего приложения.

© Habrahabr.ru