Comments 17
Реакт это не фреймворк
Прям сходу подрезал крылья автору :)
В тему здесь перевод статьи о преждевременных оптимизациях и производительности встроенных функций.
Не использовать реакт — не будет проблем
Никаких проблем https://github.com/kelseyhightower/nocode
[irony mode on]
Используйте $mol
Как избежать проблем с производительностью при создании React-приложений
Используйте $mol
Вы вот зря иронизируете. В $mol нет описанных в статье проблем так как:
Потоки данных оптимизируются автоматически. У вас не будет перерендериваться компонент выше по иерархии только лишь потому, что он передаёт что-то вложенным компонентам.
- Данные в компонент не проталкиваются напрямую, а затягиваются через функции, которые уже проталкиваются один раз при создании компонента. В терминах реакта, это выглядело бы так:
class ParentComponent extends React.Component {
shouldComponentUpdate() {
return false
}
_onClick(index) {
doSomehing(index);
}
render() {
return (
<div>
{()=> this.props.items().map((item, index) => (
<ChildComponent
onClick={() => this._onClick(index)}
/>
))}
</div>
);
}
}
class ChildComponent extends React.PureComponent {
shouldComponentUpdate() {
return false
}
render() {
return <div onClick={this.props.onClick}>{ ()=> ... }</div>;
}
}То есть компоненты игнорируют изменение props и полагаются на то, что новые функции будут давать тот же результат, что и предыдущие. Конечно этот код не заработает без forceUpdate реализованный через, например, MobX и патча реакта для приёма всех пропов в виде функций.
Во view.tree, выглядит всё это, конечно, лаконичней:
$my_parent $mol_view
items /
sub <= item_views /
Child!index $mol_child
on_click?val <=> on_item_click!index null
$my_child $mol_view
event * click?val <=> on_click?val nullexport class $mol_parent extends $.$mol_parent {
item_views() {
return this.items().map( ( _ , index )=> this.Child( index ) )
}
on_item_click( index : number ) {
...
}
}И не нужно писать статьи про 5 видов костылей, как сделать так, чтобы не тормозило.
В начале статьи были описаны три проблемы: функции, объекты и массивы. Почему в статье были предложены только решения проблем с функциями?
Новичкам может быть непонятно почему именно {{}} — антипаттерн, какие есть варианты решения.
Про map массива тоже очень интересно было бы почитать, особенно если map возвращает компоненты.
Если затронули PureComponent, почему промолчали про такие интересные проперти как children в виде компонентов, или другие проперти ожидающие node/element?
Новичкам может быть непонятно почему именно {{}} — антипаттерн, какие есть варианты решения.
Про map массива тоже очень интересно было бы почитать, особенно если map возвращает компоненты.
Если затронули PureComponent, почему промолчали про такие интересные проперти как children в виде компонентов, или другие проперти ожидающие node/element?
Да, в статье действительно описаны ответы не на все вопросы, которые могут возникнуть при передаче свойств компонентам. Очень сложно охватить всё.
Функции были выбраны потому, что проблемы с ними встречаются в коде намного чаще других. При этом статья и так получилась довольно объемной, поэтому не стал ее еще больше раздувать. Но, думаю, можно написать продолжение, где эти вопросы разбираются.
Функции были выбраны потому, что проблемы с ними встречаются в коде намного чаще других. При этом статья и так получилась довольно объемной, поэтому не стал ее еще больше раздувать. Но, думаю, можно написать продолжение, где эти вопросы разбираются.
В примере с PureComponent какое отношение к сравнению пропсов имеют
() => this._onClick()
this._onClick.bind(this)
Эти функции же через пропсы не передаются, а хранятся как свойства экземпляра класса. Зачем реакт что-то будет сравнивать. Или я чета не понял?
() => this._onClick()
this._onClick.bind(this)
Эти функции же через пропсы не передаются, а хранятся как свойства экземпляра класса. Зачем реакт что-то будет сравнивать. Или я чета не понял?
Sign up to leave a comment.
Как избежать проблем с производительностью при создании React-приложений