Использовать состояние или ссылки в компонентах формы React.js?

Question

Использовать состояние или ссылки в компонентах формы React.js?

87

Я начинаю с React.js, и я хочу сделать простую форму, но в документации я нашел два способа сделать это.

первый использует Refs:

var CommentForm = React.createClass({
  handleSubmit: function(e) {
    e.preventDefault();
    var author = React.findDOMNode(this.refs.author).value.trim();
    var text = React.findDOMNode(this.refs.text).value.trim();
    if (!text || !author) {
      return;
    }
    // TODO: send request to the server
    React.findDOMNode(this.refs.author).value = '';
    React.findDOMNode(this.refs.text).value = '';
    return;
  },
  render: function() {
    return (
      <form className="commentForm" onSubmit={this.handleSubmit}>
        <input type="text" placeholder="Your name" ref="author" />
        <input type="text" placeholder="Say something..." ref="text" />
        <input type="submit" value="Post" />
      </form>
    );
  }
});

И второй использует состояние внутри компонента React:

var TodoTextInput = React.createClass({
  getInitialState: function() {
    return {
      value: this.props.value || ''
    };
  },

  render: function() /*object*/ {
    return (
      <input className={this.props.className}
      id={this.props.id}
      placeholder={this.props.placeholder}
      onBlur={this._save}
      value={this.state.value}
      />
    );
  },

  _save: function() {
    this.props.onSave(this.state.value);
    this.setState({value: ''
  });
});

Я не вижу плюсов и минусов двух альтернатив, если они существуют. Спасибо.

santiagomaldonado 08 апр. 2015, в 00:22

Источник

0

Я что-то здесь упускаю? Почему вы не используете объект события, чтобы получить значения формы? Это, кажется, единственная причина использовать форму здесь, в первую очередь. Если вы не используете поведение отправки по умолчанию и имеете ссылки на входные данные, вам не нужно заключать их в форму.
NectarSoft 12 янв. 2016, в 02:01

Теги:

reactjs

3 ответа

76

Я видел, как несколько человек ссылаются на вышеупомянутый ответ как на причину "никогда не использовать ссылки", и я хочу дать свое (а также несколько других участников React, с которыми я говорил).

"Не использовать ссылки refs" правильно, когда вы говорите об их использовании для экземпляров компонентов. Значит, вы не должны использовать refs как способ захвата экземпляров компонентов и методов вызова на них. Это неправильный способ использования refs, и когда refs быстро выходит на юг.

Правильный (и очень полезный) способ использования ссылок - это когда вы используете их для получения значения из DOM. Например, если у вас есть поле ввода, содержащее ссылку на этот ввод, то захват значения позже через ref просто отлично. Без этого вам нужно пройти довольно организованный процесс, чтобы обновлять ваше поле ввода либо в вашем локальном штате, либо в вашем хранилище флюсов, что кажется ненужным.

Tyler McGinnis 06 янв. 2016, в 00:19

3

Ваш последний абзац имеет смысл, но можете ли вы уточнить свой второй абзац? Что является конкретным примером захвата экземпляра компонента и вызова метода, который будет считаться неправильным?
Daynil 08 янв. 2016, в 03:16
2

Я бы согласился с этим. Я использую ссылки до тех пор, пока мне не понадобится проверка или манипулирование значением поля. Если мне нужно проверить на изменение или изменить значения программно, то я использую состояние.
Christopher Davies 11 фев. 2016, в 16:27
0

Я тоже согласен с этим. На этапе открытия я специально подошел к экрану с большим количеством входов с наивностью. Все входные значения хранятся на карте (в состоянии), идентифицируемой по идентификатору. Излишне говорить, что производительность пострадала, поскольку установка состояния и рендеринг 50+ входов (некоторые материалы-пользовательские интерфейсы, которые были тяжелыми!) Для таких незначительных изменений пользовательского интерфейса, как щелчок флажка, не были идеальными. Компонентация каждого входа, который может поддерживать свое собственное состояние, казалась правильным подходом. Если требуется согласование, просто загляните в refs и получите значение состояния. Похоже, действительно хороший шаблон на самом деле.
lux 10 март 2016, в 05:37
1

Я полностью согласен. Принятый ответ слишком расплывчатый, на мой взгляд.
James Wright 10 апр. 2017, в 18:23

Показать ещё 2 комментария

2

TL; DR Вообще говоря, refs идти против React декларативной философии, поэтому вы должны использовать их в качестве крайней меры. Используйте state / props, когда это возможно.

Чтобы понять, где вы используете refs vs state / props, рассмотрим некоторые из принципов проектирования, которые следует за реакцией.

Per React документация о refs

Избегайте использования ссылок на все, что можно сделать декларативно.

Взаимодействовать с принципами дизайна Escape Hatches

Если какой-либо шаблон, который полезен для создания приложений, трудно выразить декларативным образом, мы предоставим ему императивный API. (и они ссылаются на ссылки здесь)

Это означает, что команда React предлагает избегать refs и использовать state / props для всего, что может быть сделано реактивно/декларативно.

@Tyler McGinnis предоставил очень хороший ответ , указав также, что

Правильный (и очень полезный) способ использования refs - это когда вы используете их для получения значения из DOM...

Пока вы можете это сделать, вы будете работать против философии React. Если у вас есть значение на входе, это, безусловно, происходит от state / props. Чтобы код был согласованным и предсказуемым, вы также должны придерживаться state / props. Я признаю тот факт, что refs иногда дает вам более быстрое решение, поэтому, если вы сделаете доказательство концепции, то быстро и грязно допустимо.

Это оставляет нам несколько конкретных вариантов использования для refs

Управление фокусом, выбором текста или воспроизведением мультимедиа. Выполнение обязательных анимаций. Интеграция с сторонними библиотеками DOM.

lustoykov 11 апр. 2017, в 12:08

Ещё вопросы

Я что-то здесь упускаю? Почему вы не используете объект события, чтобы получить значения формы? Это, кажется, единственная причина использовать форму здесь, в первую очередь. Если вы не используете поведение отправки по умолчанию и имеете ссылки на входные данные, вам не нужно заключать их в форму.
Ваш последний абзац имеет смысл, но можете ли вы уточнить свой второй абзац? Что является конкретным примером захвата экземпляра компонента и вызова метода, который будет считаться неправильным?
Я бы согласился с этим. Я использую ссылки до тех пор, пока мне не понадобится проверка или манипулирование значением поля. Если мне нужно проверить на изменение или изменить значения программно, то я использую состояние.
Я тоже согласен с этим. На этапе открытия я специально подошел к экрану с большим количеством входов с наивностью. Все входные значения хранятся на карте (в состоянии), идентифицируемой по идентификатору. Излишне говорить, что производительность пострадала, поскольку установка состояния и рендеринг 50+ входов (некоторые материалы-пользовательские интерфейсы, которые были тяжелыми!) Для таких незначительных изменений пользовательского интерфейса, как щелчок флажка, не были идеальными. Компонентация каждого входа, который может поддерживать свое собственное состояние, казалась правильным подходом. Если требуется согласование, просто загляните в refs и получите значение состояния. Похоже, действительно хороший шаблон на самом деле.
Я полностью согласен. Принятый ответ слишком расплывчатый, на мой взгляд.

FakeRainBrigand · Accepted Answer · 2015-04-08T03-05-00.000Z

Краткая версия: избегать ссылок.

Они плохо подходят для ремонтопригодности и теряют большую простоту рендеринга модели WYSIWYG.

У вас есть форма. Вам нужно добавить кнопку, которая сбрасывает форму.

рефов:
- манипулировать DOM
- render описывает, как выглядела форма 3 минуты назад.
состояние
- SetState
- render описывает, как выглядит форма.

У вас есть поле номера CCV на входе и некоторые другие поля в приложении, которые являются числами. Теперь вам нужно обеспечить, чтобы пользователь вводил только числа.

рефов:
- добавить обработчик onChange (не будем ли мы использовать refs, чтобы этого избежать?)
- манипулировать dom в onChange, если это не число
состояние
- У вас уже есть обработчик onChange
- добавить инструкцию if, если она недействительна ничего не делает
- render вызывается только в том случае, если он будет производить другой результат

Эх, неважно, премьер-министр хочет, чтобы мы просто сделали красную коробку, если она недействительна.

рефов:
- сделать onChange обработчик просто вызвать forceUpdate или что-то еще?
- сделать вывод вывода на основе... huh?
- Где мы получаем значение для проверки в рендере?
- вручную манипулировать элементом className dom свойство
- Я потерял
- переписать без ссылок?
- читать из dom в рендеринге, если мы монтируем в противном случае, допустим?
состояние:
- удалить оператор if
- сделать рендеринг на основе this.state

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

рефов:
- реализовать componentDidMount, componentWillUpdate и componentDidUpdate
- вручную разделить предыдущие реквизиты
- манипулировать dom с минимальным набором изменений
- эй! мы внедряем реакцию в реакции...
- там больше, но мои пальцы больно
состояние:
- sed -e 's/this.state/this.props/' 's/handleChange/onChange/' -i form.js

Люди думают, что рефссы "легче", чем держать его в состоянии. Это может быть правдой в течение первых 20 минут, это не соответствует моему опыту после этого. Положите свое "я", чтобы сказать "Да, я сделаю это через 5 минут", а не "Конечно, я просто переписал несколько компонентов".

Привет @ FakeRainBrigand, спасибо за ответ. Когда вы говорите, что в ссылках мы манипулируем DOM, вы говорите о Virtual DOM, не так ли? Конечно, если есть какие-либо изменения в Virtual DOM, это подразумевает также изменение в «реальном» DOM, но то же самое относится и к состоянию.
Не могли бы вы немного подробнее рассказать о sed -e 's / this.state / this.props /' s / handleChange / onChange / '-i form.js?
Нет, я имею в виду реальные изменения в дом. React.findDOMNode(this.refs.foo) . Если вы, например, измените this.refs.foo.props.bar ничего не произойдет.
например, если у вас есть значение <input onChange={this.handleChange} value={this.state.foo} /> измените его на значение <input onChange={this.props.handleChange} value={this.props.foo} /> , или измените ваши функции handleChange, чтобы вызывать обратные вызовы в реквизите. В любом случае, это несколько небольших очевидных изменений.
И если написание функций onChange для многополевых форм раздражает, можно просто использовать React.addons.LinkedStateMixin . Функция высокого порядка также является опцией.
@FakeRainBrigand Реферы - это нормально, если вам абсолютно необходимо измерить элементы DOM или выполнить манипуляции с DOM. В качестве простого примера, знаете ли вы, как создать анимированный вертикально сворачивающийся компонент без измерения высоты его элемента содержимого? Насколько я знаю, это единственный способ сделать это.
@ Andy, я просто имел в виду, что между defaultValue + ref (декларативное init, императивное обновление, императивное получение, состояние в dom) и значением + onChange (декларативное init, декларативное обновление, декларативное получение, состояние в js), что последнее является лучшим значением по умолчанию в реакции. Ссылки - это примитив более низкого уровня, который можно использовать для создания декларативного API (например, с использованием размера элементов).
@FakeRainBrigand круто, да, я всегда стараюсь делать вещи декларативно, если могу, но я уже сталкивался с несколькими случаями, когда ссылки были необходимы.
Не уверен, что я единственный, кто находит ваш ответ немного запутанным. Не могли бы вы показать несколько примеров кода, которые проясняют ваши моменты?
Любой из пунктов в частности? Я не собираюсь писать примеры кода для каждого
хотя написание кода для каждого из них поможет! ха-ха
При наличии более 50 входов на экране рендеринг каждого при любом изменении состояния нежелателен. Компонентация каждого поля input где каждое поддерживает свое собственное состояние, является идеальной. В какой-то момент нам нужно согласовать эти различные независимые состояния с какой-то более крупной моделью. Возможно, у нас есть автоматическое сохранение по таймеру, или мы просто экономим на componentWillUnmount Здесь я нахожу refs идеальными, во время сверки мы выбираем значение state из каждой ref , и ни один из них не является более мудрым. Я согласен, что в большинстве случаев ответом является state , но при большом количестве inputs использование правильного шаблона refs является благом для производительности.
Отличный ответ. Я просто хотел добавить еще одну связанную статью к этому вопросу, которая снова демонстрирует атрибут ref и как его обменять с локальным состоянием React.
Вы привели несколько хороших примеров. Однако, как уже говорили некоторые люди, «ref» не плох по определению - вам просто нужно знать, как его использовать, и понимать, чем он отличается от «состояния». Повторная визуализация компонента при каждой обработке ввода или создание функционального компонента для каждого поля ввода не является ни хорошей практикой, ни оптимальной с точки зрения или структуры кода, или производительности приложения.