Узкие места производительности React + Redux приложения?

Question

[Олег Драпеза]

Добрый день!

Столкнулся с лагами при разработке приложения на React и Redux.

Кейс:
50 - 100 полей ввода, каждое с уникальных reducer в хранилище.
Поле ввода - один connected компонент, оборачивает presentational компонент.
При непрерывном вводе символов в поле идет заметная задержка ввода (на каждый символ 2 action).

Для теста изменил connected компонент, теперь вместо привязки к store он хранит и изменяет значение через state.

Скорость заметно увеличилась, но подлагивания остаются!

Дебажил производительность при разных условиях, в devtools и React Perf, все сводится к тому, что React свое дело делает быстро.
В среднем, без подключения компонентов к store, общем картинка такая (10x slowdown для наглядности):
Event (keypress) длится больше чем в 5 раз, чем рендеринг компонента.



Основной вопрос - как получается, что React рендерит быстро, а приложение лагает?
Интересует любое предположение, что может быть не так.

Comments

[Никита Гущин]

Нужно больше информации. Как у вас mapState работает? Приводят ли ваши экшены к ререндеру рут компонента формы?

[Олег Драпеза]

Артём Петренков: Никита Гущин: уточню, что при изменении connected компонентов на обычные со свои state, проблемы остались (хоть и стало быстрее), чарт как раз совершенно без redux движухи. И в целом все реакт компоненты без CPU slowdown рендерятся очень быстро (по react-addons-perf).

Два action - потому что у меня кастомные redux биндинги для форм, и каждый инпут делает валидацию и изменение value, это не очень важно.

Упрощенный код с connect (Пишу на TS):

class ConnectedTextField extends React.Component<IConnectedTextFieldProps, void> {
    public componentWillMount() {
        this.props.validateField(this.props.modelValue.value);
    }
    
    public handleChange = (value: string) => {
        this.props.changeField(value);
    };

    public render() {
        const { modelValue } = this.props;

        return (
            <TextField
                value={modelValue.value}
                valid={modelValue.valid}
                onChange={this.handleChange}
            />
        );
    }
}

const mapStateToProps = (state: IStore, props: IConnectedTextFieldProps) => {
    const modelValue = resolveFieldModel(props.fieldReducerName, state);
    
    return { modelValue };
};

const mapDispatchToProps = (dispatch: Dispatch<{}>, props: IConnectedTextFieldProps) => ({
    changeField: (value: string) => dispatch(setValueThunkActionCreator(value, props.fieldReducerName)),
    validateField: (value: string) => dispatch(validateFieldThunkActionCreator(value, props.fieldReducerName)),
});

Измененный компонент:

class ConnectedTextField extends React.Component<IConnectedTextFieldProps, any> {
    public state = {
        value: '',
    }
    
    public handleChange = (value: string) => {
        this.setState({ value });
    };

    public render() {
        return (
            <TextField
                value={this.state.value}
                onChange={this.handleChange}
            />
        );
    }
}

[Никита Гущин]

Олег Драпеза: последний вариант должен без проблем работать, по идее.

А в варианте с редаксом что делает resolveFieldModel?

[Олег Драпеза]

Никита Гущин: resolveFieldModel ожидает строку - путь к нужной модели в store, с точкой в качестве разделителя, и возвращает этот кусок store. Для форм и валидации я написал примитивный вариант react-redux-forms, многое нужно доработать, поэтому на его производительность я не жалуюсь.

Меня очень смущает итоговый devtools perfomance график, и то что react-addons-perf показывает адекватную скорость рендеринга, даже при самых плохих условиях (на ввод 1 символа):


И даже если бесполезные (Wasted) срабатывания свести к нулю через shouldComponentUpdate, лучше не становится.

[Максим]

Олег Драпеза помню 2 года назад, я дико намучался с инпутами. Код тогда был ужасен, НО помогла мне найт сборка хрома =) оказалось с производительностью был баг в текущей версии браузера. Я не вчитывался в ваш вопрос, да и тогда давно я только изучал реакт, просто на всякий случай проверьте в других браузерах. В хроме найтли, в сафари, в ФФ, в IE последнем, в опере. Возможно добавится какой-то информации.
P.S. в любом случае, буду признателен, если после решения проблемы черканете статейку на хабр со всеми скринами, профилированием, процессом и тд - многим поможет! Плюс, если повезет, придет пара критиков с хорошими идеями.

[Олег Драпеза]

Максим: Вы правы, сильнее всего тормозило в Canary, в обычном Chrome и Firefox не так заметно.

Статью было бы интересно написать, если найдется настоящая и интересная причина, которую удастся решить - а так то полно статей по производительности React приложений)

А что вы думаете по поводу того, что компонент может 2мс обновляться, а общая обработка keypress больше 10мс? Это по результатам flamechart в хроме.

[Максим]

Олег Драпеза: нет ответа, к сожалению.

[Никита Гущин]

Олег Драпеза: ну, TextField в любом случае лучше сделать React.PureComponent, а не React.Component

[Олег Драпеза]

Никита Гущин: пробовал и так, и делал самостоятельно shouldComponentUpdate необходимый - увы это не решает проблему, так как по всем тестам компоненты быстро обновляются. Возможно я неправильно читаю графики)

Answer 1

[Роман Макаров]

1. Производительность тестить нужно только в прод билде. (Гуглить react production build)
2. Чаще всего bottleneck в redux приложениях - это shouldComponentUpdate и нерациональное использование пропсов. (Тут читать доки про scu, reselect, и pureComponent)
3. Store должен быть максимально плоским, т.е. содержать минимальную вложенность (вытекает из п.2)

Comments

[Роман Макаров]

Если стадия проекта позволяет, очень рекомендую mobx. Там достаточно п1 чтобы быдо быстро