Должен ли компонент Generact React List получать реквизиты или слушатели от родителя?

Question

Это несколько больше вопросов о стиле/теории, так как я ДУМАЮ, что оба метода будут работать. Вот сценарий:

У меня есть компонент InfiniteList, который я хочу сохранить родовым. Он получает текущий список всех идентификаторов элементов из родителя, затем вычисляет, какие из них он должен отображать. Для этого я в основном вытаскиваю соответствующие идентификаторы из списка, а затем отправляю полные данные по идентификатору из магазина.

Мой вопрос заключается в следующем: чтобы сохранить его универсальным, очевидно, что компонент бесконечного списка не может действительно жестко указывать, в каком хранилище он должен получать данные полного элемента (например, у меня есть 10 разных типов предметов, все из которых имеют свой собственный магазин). Тем не менее, для меня более разумно, что прокрутка и изменение набора отображаемых элементов - это состояние. Итак, как вы думаете, имеет смысл:

A) Передайте список IDS в качестве реквизита, а также добавьте/удалите слушателей из родительского компонента, чтобы компонент списка знал, кого слушать?

B) Или имеет смысл просто передать как список, так и полный набор данных элемента, доступных в качестве реквизита, и чтобы родительский компонент прослушивал соответствующий магазин?

Часть мотивации «прослушивания» заключается в том, что если в магазине нет элементов, они должны их получить, поэтому мне нужно, чтобы список был повторно зарегистрирован после обновления itemStore.

Вдохновленные частично здесь: ReactJS: Modeling Bi-Directional Infinite Scrolling

Answer 1

Я бы с В по следующим причинам:

1) Я думаю, что это приведет к наиболее общему компоненту, потому что это не нужно знать что-либо о том, откуда поступают данные или как они обновляются.

2) Компонент не имеет состояния.

3) код для прослушивания событий Store и обновления состояния компонента, вероятно, настолько короток, что вы не получите значительной выгоды от его перемещения в компонент.

Единственное преимущество, которое я видел в A, заключается в перемещении, которое хранит обработку событий в компоненте, поэтому вам не нужно переписывать его. Но сделав это, вы заставите свой компонент иметь состояние. Может быть, в этом случае это достаточно просто, неважно. Это действительно зависит от приложения. Если компоненты, расположенные выше в иерархии (родители InfiniteList), также будут повторно отображаться на событиях из одного и того же магазина, я бы уклонился от того, чтобы InfiniteList снова переделал себя в одно и то же событие. Если вы InfiniteList - это - единственный компонент, который необходимо будет обновить на этом событии, тогда имеет смысл иметь состояние в InfiniteList, но это вряд ли будет иметь место во всех случаях. Я снова склоняюсь к B как более общий.

Это, как говорится, если вы действительно хотели, чтобы сохранить переписывания логики обработки события, и если вы используете один и тот же подход, от React учебников, я бы использовать этот факт и просто передать Сохранять себя в качестве опоры , В примерах магазины создаются путем наследования от EventEmitter.prototype. Если вы создадите каждый из своих магазинов таким образом, вы знаете, что он будет иметь метод addListener() и removeListener(). Кроме того, вы можете потребовать, чтобы каждый магазин имел методы getItemIds() и `getItem (id) '. Если вы хотите явно указать, что объект, переданный в ваш компонент React, имеет все эти методы, вы можете использовать propTypes with isRequired.Например:

//YourComponent.js 

var YourComponent = React.createClass({ 
    propTypes:{ 
    // assuming ListModel has been defined with the methods you need 
    listModel: React.PropTypes.instanceOf(ListModel).isRequired, 
    // assuming you're using the EventEmitter, like in React example code 
    modelEvent: React.PropTypes.string.isRequired 
    }, 

    getInitialState: function(){ 
    // start with an empty array 
    return { items: [] }; 
    }, 

    componentDidMount: function(){ 
    var evt_handler; 

    // when the model changes, get the list again 
    evt_handler = (function(){ 

     this.setState({ items: this.props.listModel.getItemIds() }); 
    }.bind(this)); // bind to maintain context 

    // register for events 
    this.props.listModel.addListener(this.props.modelEvent, evt_handler); 
    }, 

    render: function(){ 
    ...do your filtering, make it pretty 
    } 
}); 

Это явно меньше общего, чем лица без подхода В и на самом деле просто стилистическая альтернатива прохождения сами функции, но в любом случае, я бы использовать propTypes с isRequired для функций ,