Я читаю книгу Fullstack React, и в своем примере проверки формы они создают свой собственный компонент поля (стр. 204-212), а затем сохраняют значение поля как в состоянии поля, так и в родительском состоянии, что сбивает с толку меня. Их компонент Field имеет свойство value, а также состояние, содержащее value. Родительский компонент должен знать о каждом значении поля, чтобы он мог выполнять проверку формы в целом, и поэтому он также имеет состояние, содержащее value.
Внутри поля они обрабатывают изменения value, устанавливая состояние поля при изменении входного value и используя getDerivedStateFromProps при изменении свойства value:
//(within Field)
getDerivedStateFromProps(nextProps) {
return {value: nextProps.value}
}
onChange = evt => {
const name = this.props.name;
const value = evt.target.value;
const error = this.props.validate ? this.props.validate(value) : false;
this.setState({value, error});
this.props.onChange({name, value, error});
};
Они также синхронизируют состояние значения в другом направлении с родительским, вызывая родительскую функцию onInputChange (переданную как свойство onChange):
//(within parent component)
onInputChange = ({name, value, error}) => {
const fields = Object.assign({}, this.state.fields);
const fieldErrors = Object.assign({}, this.state.fieldErrors);
fields[name] = value;
fieldErrors[name] = error;
this.setState({fields, fieldErrors});
};
В книге на самом деле не объясняется, почему они дублируют такое состояние, за исключением того, что говорится:
"There are only two pieces of data that Field will need, the current value and error. Like in previous sections where our form component needed that data for its render() method, so too does our Field component."
а также
"One key difference is that our Field has a parent, and sometimes this parent will want to update the value prop of our Field. To allow this, we’ll need to create a new lifecycle method, getDerivedStateFromProps() to accept the new value and update the state."
Я просто новичок, но, на мой взгляд, было бы разумнее полностью отказаться от состояния value в Field и просто передать его как опору. Когда ввод изменяется, вызовите метод onChange с полем и вызовите родительский onInputChange внутри него. Попросите onInputChange обновить родительское состояние о значении поля и передать значение поля в качестве опоры в поле. То, как это делается сейчас, кажется излишним и более подверженным ошибкам. Любое понимание того, почему они делают это таким образом?
Вы попали в точку, единственный вариант использования, который я могу придумать для дублирования состояния в дочернем компоненте, - это попытка каким-то образом сохранить исходное состояние.
Единственная причина, по которой я могу увидеть, продолжается ли пример, где вы должны строить поверх этого, где имеет смысл разделить состояния между дочерними и родительскими состояниями. Но даже в этом случае это, вероятно, ведет к путанице в архитектуре React. Я поделюсь своими двумя центами, даже до сих пор я не прочитал хороший учебник по React и даже не прошел хорошо написанный оценочный тест React. Все мои навыки React основывались на примерах самого сайта React и Redux.
@JonasW. Спасибо :) Но интересные ребята, думаю, позже посмотрю, есть ли в этом смысл.
@josephnvu Мне пока нравится эта книга, так что, надеюсь, она обретет смысл позже, или это всего лишь один запутанный пример: T
Сохранение локального значения может иметь смысл, если вы обновляете родительское значение только в том случае, если оно действительно. У меня есть проверяющий входной компонент, который делает именно это. Может быть, они работают над чем-то подобным в вашей книге?
Я не считаю эту настройку проблематичной. Формы - не ваш типичный компонент; вы часто найдете этот общий шаблон с библиотеками форм, где отдельный компонент поддерживает свое собственное состояние, но затем уведомляет родительский, который, в свою очередь, должен агрегировать состояние отдельных лиц и запускать глобальную проверку.
@Oblosys Я сомневаюсь в этом, я думаю, они хотят обновить родительский элемент в любом случае.



![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)


Книгу не читал, но здесь я объясню, зачем мне писать такой код.
Главное в наличии двух состояний - сделать компонент Field более универсальным.
В этом конкретном случае родитель также сохраняет значение в своем состоянии, и компонент Field становится управляемым компонентом, обновляя свое состояние из полученного props на getDerivedStateFromProps.
Однако все еще существует возможность использовать компонент Field как неконтролируемый компонент, тогда состояние Field будет единственным источником истины.
В обоих случаях есть только один источник истины, который поддерживает способ действий React, однако компонент Field может использоваться как в контролируемой, так и в неконтролируемой форме.
Ах хорошо. В этом есть большой смысл. Раньше они говорили о преобразовании своих форм ввода из неконтролируемых (с использованием ref) в контролируемые компоненты и о том, что они действительно не рекомендуют неконтролируемые. Но я предполагаю, что они сделали это здесь, чтобы все еще могло работать неконтролируемо.
Я полностью согласен с тобой. Они обязательно должны поднять состояние и сохранить единый источник правды.