Comments 16
Забивать редакс всяким мусором не лучшая идея…
Раз уж тут речь идет о функциональных компонентах, полезным будет упомянуть библиотеки recompose и recompact.
В них уже есть много полезных утилит для функциональных компонентов, в том числе и pureComponent, приведенный в статье.
Можно через HOC и statefull функциональные компоненты делать.
Да, только не вижу профита.
Без редакса берем и
Выкидываем: объявление класса, constructor(), render(), const для деструктуризации props, this.
Покажите пример. Я себе плохо не представляю.
Может быть, речь об этом?
import {withState} from 'recompose';
const Counter = ({ counter, setCounter }) =>
<div>
Count: {counter}
<button onClick={() => setCounter(n => n + 1)}>Increment</button>
<button onClick={() => setCounter(n => n - 1)}>Decrement</button>
</div>
)(Counter);
export default withState(
'counter', // имя значения
'setCounter', // имя коллбека для его обновления
0 // начальное значение
)В документации recompose есть и более интересные примеры.
const withState = (f, defaultState = {}) => class extends Component {
render () {
return f({
state: this.state || defaultState,
setState: this.setState.bind(this)
})
}
}
const Counter = withState(({ state, setState }) => (
<span>
<button onClick={() => setState({ count : state.count - 1 })}>
-
</button>
{state.count}
<button onClick={() => setState({ count : state.count + 1 })}>
+
</button>
</span>
), { count : 0 })
Думаю, основная идея ясна.
Ещё желательно преодолеть коннектобоязнь — не тащить все свойства через родительские компоненты, а применять connect() для дочерних компонентов по мере использования свойств
State компонента в Redux VS локальный state компонента — какова разница по производительности?
Redux state может быть тяжелым и очень ветвистым с туевой хучей редьюссеров и десятком middleware, каждый dispatch(action) будет прогоняться через всю эту мясорубку.
Если например текстовый контрол хранит displayText в redux, то набор каждой буквы будет адово влиять на производительность и лагать на слабых машинах, особенно в IE, в таком случае надо все равно коннектится на стейт и юзать функциональные компоненты?
State компонента в Redux VS локальный state компонента — какова разница по производительности?На этот вопрос отвечают разработчики мобильной веб-версии Twitter в своём недавнем посте: https://medium.com/@paularmstrong/twitter-lite-and-high-performance-react-progressive-web-apps-at-scale-d28a00e780a3 (см. секцию «Optimizing Redux»).
Если кратко: отказавшись от состояния в Redux в некоторых местах в пользу локального состояния удалось получить прирост производительности 50%.
или перенести всё состояние в стор redux-а (как единственный источник правды). Локальные состояния компонентов — это дополнительный уровень абстракции, требующий обслуживания. А зачем?
Глобальный стор redux-а со всем его бойлерплейтом — дополнительный уровень абстракции (причём далеко не элементарный) для хранения и управления локальным состоянием.
Ещё желательно преодолеть коннектобоязнь — не тащить все свойства через родительские компоненты, а применять connect() для дочерних компонентов по мере использования свойств.
А если это не "коннектобоязнь", а желание максимально снизить зависимость от redux, чтобы его замену на что-то другое произошла максимально безболезненно?
Ещё желательно преодолеть коннектобоязнь — не тащить все свойства через родительские компоненты, а применять connect() для дочерних компонентов по мере использования свойств.
А если это не «коннектобоязнь», а желание максимально снизить зависимость от redux, чтобы его замену на что-то другое произошла максимально безболезненно?
Если работать в парадигме «умных» и «глупых» компонентов, то ваши коннекторы просто заменятся на другие «умные» компоненты в mobX и проч. Это всегда лучше, чем прокидывать миллиард пропсов из верхнеуровнего компонента (SomePage и проч.) — это всегда превращается в {...this.props} на каждый дочерний компонент и потом сложно отследить и отладить, откуда все взялось, плюс лишние пропсы попадают.
Коннектор это просто обертка, чаще всего ему и разметка не нужна:
export default connect(mapStateToProps, mapDispatchToProps, mergeProps)(MyDumbCompoent)
UFO just landed and posted this here
не нужно конвертировать если нужны life-cycle методы
Но это неточно. :)
Sign up to leave a comment.
Функциональные компоненты