Блог

Наша команда работает с React Native уже почти год, и одна из проблем, с которыми мы столкнулись на раннем этапе, — это скорость рендеринга. В нашем приложении есть несколько компонентов, которые пользователю необходимо перетаскивать, и изменения состояния (в сочетании с shouldComponentUpdate) были просто недостаточно быстрыми для достижения этой цели.

Мы обошли это двумя способами, и мне было интересно, в какой степени эти методы являются кошерными по сравнению с хакерскими.

Прямое манипулирование и setNativeProps — Мы так часто использовали setNativeProps, что создали фреймворк, подобный Redux; однако вместо изменения состояния он использует setNativeProps для ускорения. Целью этого было расширить setNativeProps за пределы его использования исключительно внутри компонента; однако мы по-прежнему используем изменения состояния, когда это возможно.

Scrollview и TextInput — нам удалось поворачивать и ориентировать Scrollviews и TextInput таким образом, чтобы работать с setNativeProps, чтобы перетаскивание содержимого было более плавным и естественным, а текст можно изменять быстрее, чем позволяет изменение состояния.

Нам было интересно, насколько все это кошерно, поскольку веб-сайт React Native отмечает только его сложность:

setNativeProps является обязательным и сохраняет состояние на собственном уровне (DOM, UIView и т. Д.), А не в ваших компонентах React, Что затрудняет анализ вашего кода.

Должны ли мы переделать наше приложение?

Вызов setNativeProps не рекомендуется, но я не считаю это огромным красным флагом, если он позволяет вам достичь желаемого качества. Как предупреждают документы, это усложняет анализ вашего кода, поскольку он задает состояние в ваших собственных представлениях, которого нет в вашей иерархии компонентов React.

Два способа укротить эту сложность — уменьшить количество различных фрагментов кода, которые могут устанавливать реквизиты через JSX или setNativeProps для данного компонента, и постепенно отказаться от setNativeProps и уменьшить рендеринг с shouldComponentUpdate помощью и PureComponent вместо этого.

Неизменяемые структуры данных упрощают реализацию shouldComponentUpdate , а также повторный выбор селекторов, если вы используете Redux. Если ваши часто отображаемые компоненты имеют render() методы, которые создают много элементов, преобразуйте группы этих элементов в чистые компоненты, которые необязательно должны отображаться так часто. Преобразование Вавилона с постоянными элементами устраняет большую часть стоимости элементов, которые никогда не меняются, создавая их только один раз; когда React видит один и тот же элемент через два последовательных render() прохода, он не будет повторно отображать элемент во второй раз.