2015-09-25 5 views
1

Что такое канонический способ React + Flux для компонентов идентификатора, которые вызывают изменение состояния?Как определить компоненты, которые вызывают изменение состояния в React + Flux?

У меня есть приложение, которое позволяет пользователю создавать палитры с использованием цветового пространства HSL.

Вот компонент структура моего приложения:

Container (this component gets state and passes it down the chain) 
| PalettePicker 
    | ColorPicker 
    | Slider (this component fires action) 
    | Slider 
    | Slider 
    | (As many ColorPickers as colors) 
| ImageSamples (not relevant, but dependent on palette) 

Вот взгляд на ColorPicker компонента:

ColorPicker component

Каждый ColorPicker содержит 3 Slider компоненты, которые вызывают события, которые обновляют магазин. Затем магазин обновляет палитру и передает всю палитру вниз до компонента Container, который передает его в виде props своим дочерним компонентам.

Вот моя функция, которая обрабатывает событие изменения ползунка в моем Store (я использую рефлюкс):

sliderChange: function(newValue) { 
    var modifiedPalette = this.palette; 
    modifiedPalette[newValue.colorIndex][newValue.colorPartsIndex] = newValue.value; 
    this.trigger(modifiedPalette) 
} 

Моей палитра представляет собой массив HSL значений цветов, так что-то вроде:

[ [350, 100, 50], [340, 100, 40], ... ]

«Цвет» - это один из массивов из 3 элементов выше, и я называю каждый элемент в цветовом массиве «цветной частью», поскольку он представляет собой цвет H, S или L.

Передача цвета и цветной части индекса вниз, поскольку пропеллер кажется неэлегантным. Я в настоящее время строит компоненты, как это:

colorPickers = palette.map(function(color, i) { 
    return (
     <ColorPicker 
      key={i} 
      colorIndex={i} 
      color={color} 
     /> 
    ) 
}); 

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

Что такое идиоматический метод React + Flux?

+0

Использование colorIndex - это хорошо. Не следует, чтобы цвет = {this.props.palette [i]} был цветом = {цвет}. –

+0

Спасибо, должен быть {color} –

+0

@MattParrilla, который зависит от того, сколько цветов вы можете изменить сразу. Если только один - вы можете сохранить свойство currentColor в своем магазине и aviod, передавая указатель цветового индекса. Но если вы можете изменить несколько комбинаций - чем у вас есть отношения с одним-двумя магазинами, и я не вижу лучшего способа. На самом деле, почему вы думаете, что это неэлегантно? –

ответ

1

Я бы предложил не дать компоненту ColorPicker вызывать любое действие самостоятельно, но передать его как опору «onChange». Ему не нужно знать, какой именно индекс. Вы можете связать функцию OnChange так, что она будет проходить индекс:

colorPickers = palette.map(function(color, i) { 
    return ( 
     <ColorPicker key={i} 
      onChange={this.changeColor.bind(this, i)} 
      color={color} 
     /> 
    ) 
}); 

Функция changeColor выглядит следующим образом:

changeColor : function(colorIndex, colorArray) {...} 

Он должен получить весь цвет (массив) и огнь соответствующих Действие рефлюкса с ним и индекс. Таким образом, ColorPicker должен только активировать функцию onChange с новым измененным цветом.

Выполните те же самые трюки для каждого слайдера внутри панели выбора цвета. Передайте ему функцию onChange, которая уже ограничена его partIndex. Когда эта функция запускается, ColorPicker должен построить новый массив цветов и вызвать его собственный onChange prop.

Надеюсь, что это было достаточно ясно. Мотивация - каждый компонент должен получить простую функцию обратного вызова и выводить только то, за что он несет ответственность.Ему не нужно знать никаких других деталей. Вместо того, чтобы передавать все больше бесполезных указателей на указатели до конца, просто передайте ограниченные обратные вызовы. Это упростит ваши компоненты и позволит вашему высокоуровневому компоненту разобраться с деталями построения самого действия Flux.

+0

Это было похоже на мою первоначальную реализацию, но у меня было несколько сотрудников, указывающих, что использование обратных вызовов не было чистым "одним поток данных ». Тогда возникает вопрос: должны ли мы быть абсолютистами, когда дело касается направления потока данных? Если нет, то где линия? –

+0

Интересно, что некоторые доказательства в пользу обратных вызовов из учебника Facebook: https://facebook.github.io/react/docs/tutorial.html#callbacks-as-props –

+1

Я думаю, что передача обратных вызовов по-прежнему демонстрирует «одно направление» поток данных ". Вся идея «данные вниз, действия вверх» с Flux заключается в том, что компоненты не должны напрямую изменять другие компоненты, а вместо этого отображать модель и, возможно, срабатывать, что может изменить эту модель. IMO - компонент высокого уровня, который пропускает обратные вызовы, но запускает само действие (и только затем получает его новые данные), по-прежнему является прочной реализацией этого принципа. – lyosef

Смежные вопросы