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

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

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

В этом эпизоде заметно, что простой виджет 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 на заглушку, как мы делали в эпизоде про регистрацию.