Локальное состояние и хуки

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

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

В этом эпизоде заметно, что простой виджет Clock спокойно перешёл на локальное состояние. Но как только мы всё состояние с лотами и экшены со stream и api перенесли внутрь Lots этот компонент сразу стал монструозным и почти нетестируемым. Так что не всегда очевидно что будет удобнее.

То есть этот компонент:

function ClockContainer () {
  const [time, setTime] = React.useState(new Date())

  React.useEffect(() => {
    const interval = setInterval(() => setTime(new Date()), 1000)
    return () => clearInterval(interval)
  }, [setTime])

  return <Clock time={time} />
}

Выглядит более громоздким, чем этот?

class ClockContainer extends React.Component {
  constructor () {
    super()
    this.state = {
      time: new Date()
    }
    this.tick = this.tick.bind(this)
  }

  tick () {
    this.setState({
      time: new Date() 
    })
  }

  componentDidMount () {
    this.interval = setInterval(this.tick, 1000)
  }

  componentWillUnmount () {
    clearInterval(this.interval)
  }

  render () {
    return <Clock time={this.state.time} />
  }
}

Интерфейс шрифтом Tahoma
В редакторе DejaVu Sans Mono

Да, LotPage в плане состояния и загрузки будет работать абсолютно также как Lots. Он будет брать id из маршрутизатора и у себя подгружать текущий лот.

Если с api всё будет в одном компоненте, то тогда со всеми хуками нужно будет тестировать весь компонент через React Testing Library. И там подменять переменную global.fetch или модуль api на заглушку, как мы делали в эпизоде про регистрацию.

Да, весьма странный подход. Надо спросить у авторов этого кода.

Все ради экономии пары строк кода?

Да, для экономии десятка строк кода.

А чем плох redux?

Глобальный state со всеми данными на весь проект плох тем, что облегчает нарушение дисциплины, когда какой угодно программист в любом своём компоненте может обратиться к чему угодно. Это может привести к запутанному коду, когда не понятно, кто из тысячи компонентов что использует из тысяч полей. В отличие от этого локальное состояние заставляет программировать более аккуратно и все передачи значений наружу производить только когда это действительно понадобится.

А конкретно сам Redux многим неудобен по причине неэкономии строк кода. Что для любого изменения какого-то поля приходится прописывать кучи кода в виде действия, фабрики и ветки в редьюсере. Вместо него часто выбирают Mobx, где столько кода не нужно.