предисловие
Я только что отпраздновал день рождения моей мамы, и поддельный баланс вот-вот будет недостаточен. Друзья веселятся? В любом случае, я мертв дома, я не пошел играть, и я не учился усердно дома. Это позор. Нет, сегодня я поделюсь с вами несколькими способами обновления пользовательского интерфейса на основе реакции.Все они говорят, что реакция — это односторонний поток данных и пользовательский интерфейс, управляемый данными, так что вы знаете, что есть несколько способов управлять обновлением представления в реакции.
1. setState
setState — наиболее распространенный способ обновления представления, вам нужно только указать начальное состояние, когда вам нужно обновить, вызовите this.setState, и компонент пройдетshoudlComponentUpdate => componentWillUpdate => render => componentDidUpdateЧетыре процесса, если нет ручного возврата false в shouldComponentUpdate, то пользовательский интерфейс будет обновлен в это время.
Следует отметить, что хотя параметр this.setState({}) является пустым объектом, реакция будет обновлять его, вызывая четыре вышеуказанных жизненных цикла, но представление пользовательского интерфейса не изменится.
Конечно, все они основаны на компонентах класса, потому что setState — это метод прототипа Component, и для вызова this.setState должен быть компонент, наследующий Component. (Я написал предыдущий постСтатья о setStateТе, кто заинтересован, также может пойти и увидеть. )
2. forceUpdate
Calling forceUpdate() will cause render() to be called on the component, skipping shouldComponentUpdate(). This will trigger the normal lifecycle methods for child components, including the shouldComponentUpdate() method of each child. React will still only update the DOM if the markup changes.
Официальное заявление относительно ясное. После вызова forceUpdate текущий компонент пропустит хук shouldComponentUpdate. Даже если он вернет false вручную, он также будет обновлен. Буквальное понимание этого слова такжеПринудительное обновление, но следует отметить, что обновлением дочерних компонентов по-прежнему будет управлять shouldComponentUpdate .
Normally you should try to avoid all uses of forceUpdate() and only read from this.props and this.state in render().
Сценарий использования forceUpdate, как правило, заключается в том, что обновления представления поступают из других данных, не являющихся состоянием и реквизитами, таких как свойства, привязанные к экземплярам компонента, или напрямую измененные.this.state.xxx= xxx , а затем вызовите this.forceUpdate(), но это официально не рекомендуется.В обычных обстоятельствах вам следует избегать использования forceUpdate и обновлять представление через состояние или реквизиты.
3. Нативные манипуляции с домом
В React неизбежно работать с собственным DOM, например, если вы используете стороннюю библиотеку, такую как jquery, которая должна получить DOM, или вам нужно реализовать перетаскивание, масштабирование и масштабирование. компонент, для них вы можете использовать операцию. Метод dom обходит реакцию setState, а затем серию вычислений dom diff, напрямую обновляет dom и немного улучшает производительность.
Вышеупомянутые три способа обновить пользовательский интерфейс, у меня есть один здесьDemo, Следует отметить, что когда цвет меняется на красный через обновление setState, а цвет меняется на зеленый после нажатия нативной кнопки DOM, то при нажатии кнопки setState обнаруживается, что представление не обновляется, а функция рендеринга все еще выполняется. Это связано с тем, что нажата собственная DOM. Перед кнопкой значение this.state.backgroundColor красное, а собственная операция — это непосредственно измененный стиль dom. Когда вы снова нажимаете кнопку setState , значение this.state.backgroundColor по-прежнему красное.Хотя логика обновления исчезла из-за нового и старого React. пользовательский интерфейс.
4. dispatch action
Вышеупомянутое несколько способов реагировать само по себе приходит с состоянием для обновления пользовательского интерфейса, при использовании в редуксе проекта мы обычно выполняем действие отправки, изменяя хранилище, а затем обновляя пользовательский интерфейс, действие отправки, изменяя реквизиты для просмотра всех когда вы когда-нибудь задумывались, почему this.props.dispatch ({type: 'xxx'}), вы можете обновить его?
Вот краткое введение. Когда мы отправляем действие, мы вызываем store.dispatch. Это не проблема. Store.dispatch запустит все редукторы, зарегистрированные в createStore, и найдет соответствующий тип для обновления данных. Возвращает новое состояние.
Если наш компонент хочет получить данные хранилища, он должен передать connect(mapStateToProps, mapDispatchToProps)(App). Таким образом, компонент Connect в react-redux вызовет componengDidMounttrySubscribeметод, который внутренне вызывает store.subscribe для подписки наhandleChangeМетоды.
Таким образом, когда вы отправляете действие, запускается метод в компоненте Connect, а компонент Connect также поддерживает метод с именемstoreStateКаждый раз, когда вы получаете новое сотре, вызывайте setState для запуска функции рендеринга.Функция рендеринга выполнит действие слияния реквизитов в соответствии с параметрами mapStateToProps и mapDispatchToProps, переданными в вашем подключении, включая необязательный параметр mergeProps, и, наконец, в Connect внутри компонент возвращаетcreateElement(WrappedComponent,this.mergedProps)Такая штука, а второй параметр createElement — это пропсы вашего компонента, так что каждый раз, когда пропсы меняются, он будет управлять обновлением представления. Это принцип ведения дел в Redux.Конечно, описание здесь относительно короткое.В следующий раз я напишу отдельную статью про реакт, редукс и реакт-редукс.
Суммировать
- Измените состояние, вызвав this.setState для управления представлением.
- Принудительно обновите представление, вызвав this.forceUpdate .
- Обновите представление, манипулируя собственным домом.
- Управляйте представлениями, изменяя реквизиты (сокращение или изменение родительского и дочернего компонентов для передачи реквизитов).