Как мы отказались от styled-components в React Native приложениях22.11.2023 11:16

Привет! Меня зовут Виталик, я Тимлид команды UI-kit в Профи.

Styled-components является стандартом написания стилей для многих команд, которые разрабатывают приложения на React Native. Но мы не всегда задумываемся, зачем мы тащим это в продукт и какую выгоду получим. А что если от styled-components больше вреда, чем пользы? Я поделюсь нашим опытом в Профи и попробуем разобраться вместе.

Какие проблемы

У Профи есть 2 мобильных приложения на React Native, которые написаны с использованием styled-components. Для этих приложений существует одна дизайн-система и UI-kit. 

Мы накопили несколько проблем, связанных с UI, во всех этих продуктах:

Мы взялись за исследование этих проблем. У нас было предположение, что именно styled-components сильно замедляет рендер. При этом скорость UI является одной из ключевых метрик для продукта. В этот момент мы начали изучать возможность отказа от styled-components. Стали рассматривать другие варианты стилевых фреймворков, которые заодно решили бы и другие проблемы.

Варианты подходов

1. Оставить styled-components
   Проблему с производительностью не решить, но можно отдельно решить другие 2 проблемы.

2. Добавить styled-system
   Styled-system — это дополнение к styled-components. Библиотека позволяет строить UI с использованием специальных атрибутов, которые формируются на основе токенов дизайн-системы. Опять же, производительность лучше не станет, но можно было элегантно решить другие проблемы.

3. Перейти на Restyle
   Restyle — это библиотека для RN. Она помогает выстраивать UI, используя специальные атрибуты. Атрибуты формируются на основе токенов дизайн-системы. Основное отличие от styled-system в том, что это библиотека не использует styled-components под капотом. Такой подход решил бы все проблемы.

4. Перейти на Tailwind
   Tailwind — это технология для веба, но есть и решения для React Native. Все стили создаются через предопределенные классы на все случаи. Дальше вы увидите пример как это выглядит в коде. Подразумевалось, что производительность будет лучше за счет кэширования стилей. Такой подход решил бы все проблемы.

5. Использовать нативный StyleSheet
   В этом варианте мы будем использовать нативный инструмент StyleSheet.create для создания стилей без дополнительных библиотек. Таким образом можно решить все проблемы.

Замеры скорости рендера

Для начала мы произвели замеры скорости всех вариантов. Нам нужно было подтвердить гипотезу, что styled-components действительно замедляет рендер приложения. Заодно мы получили важные данные о скорости рендера других вариантов. Это поможет нам при выборе целевого подхода.

Для теста создали компонент в пяти вариантах. Компонент внешне получился не очень естественный, но для нас важнее было сделать максимально тяжелый и репрезентативный компонент:

• он содержит 100 строк,

• в каждой строке есть номер, созданный шрифтом из ДС,

• в каждой строке 20 блоков, с радиусом из ДС и рандомным цветом из ДС.

Скриншот экрана с компонентом

Проводилось 10 замеров рендера для каждого варианта, затем для результата бралось среднее значение.

Измерялось время рендера следующим образом:

export const Component = () => {
  const start = new Date().getTime();
  useEffect(() => {
    const renderTime = new Date().getTime() - start;
    console.log(renderTime);
  }, []);

  return (
    ...
  );
};

Результаты замеров

Вариант без дополнительных библиотек оказался самым быстрым — рендер компонента занял всего 408 ms. Второй по скорости вариант — это Restyle. 

Styled-components действительно сильно замедляет рендер UI. Время отрисовки компонента заняло 632 ms. Мы подтвердили нашу гипотезу. Styled-system еще больше усугубляет ситуацию и увеличивает время рендера, потому что создает дополнительный слой абстракции на токены.

Скорость интерфейса в нашем приложении очень важна. А styled-components уже ничего не могло спасти. Поэтому уже в этой точке мы приняли решение отказываться от вариантов со styled-components.

❌ Styled-components
❌ Styled-system

У нас осталось 3 варианта на выбор: Restyle, Tailwind или StyleSheet.

Примеры кода Restyle & Tailwind & StyleSheet

Рассмотрим пример каждого подхода, чтобы понять, как он будет выглядеть стилистически. Стиль и сложность кода — один из важных критериев для выбора подхода.

Код был составлен для типичного компонента из приложения:

• отступы из ДС, кратные 4 px,

• радиус из ДС,

• несколько вариантов шрифта из ДС,

• пример компонента Button из UI-kit,

• цвет текста и бэкграунд из ДС.

Внешний вид компонента

Ниже в спойлерах можно посмотреть примеры кода каждого варианта.

Restyle

import {Box, Text, Button} from '@profi/uikit-rn';

const RestyleExample = ({ onPress }) => {
  return (
    
      
        Найдем любого профи - просто создайте заказ
      
      
        Создать заказ
      
    
  );
};

Tailwind

import {Text, View} from 'react-native';
import {Button} from '@profi/uikit-rn';
mport {useTailwind} from 'tailwind-rn';

const TailwindExample = ({ onPress }) => {
  const tw = useTailwind();
  return (
    
      
        Найдем любого профи - просто создайте заказ
      
      
        Создать заказ
      
    
  );
};

StyleSheet

import {Text, View} from 'react-native';
import {Heading, Typography, Button} from '@profi/uikit-rn';
import {TOKENS} from 'tokens';

const StyleSheetExample = ({ onPress }) => {
  return (
    
      
        Найдем любого профи - просто создайте заказ
      
      
        Создать заказ
      
    
  );
};

const styles = StyleSheet.create({
  container: {
    backgroundColor: TOKENS.colors.g300,
    borderRadius: ${TOKENS.radiusM.xl},
    padding: 16px;
  },
  titleText: {
    marginBottom: 20,
    color: TOKENS.colors.g500,
  },
  buttonText: {
    color: TOKENS.colors.g100,
  },
});

Что здесь сразу же бросается в глаза — Restyle и Tailwind выглядят очень похоже стилистически. В Restyle стили указываются атрибутами, а в Tailwind — классами. Но даже сами названия выглядят похоже.

Tailwind VS Restyle

В этом моменте у нас возникло разногласие. Часть разработчиков была категорически против того, чтобы писать стили атрибутами. Часть была против того, чтобы писать классы.

Мы провели опрос среди разработчиков. В опросе был прикреплен вариант с кодом Restyle и Tailwind. И задан следующий вопрос:

Какой стилевой фреймворк тебе нравится больше — Restyle или Tailwind? Оцени каждый вариант от 1 до 5, где 1 — это очень плохо, а 5 — просто супер. Оценивай по личным критериям (читаемость, легкость написания, масштабируемость)

Результаты опроса

По результатам опроса поняли, что Tailwind вариант почти никому не нравится стилистически. К тому же он создавал дополнительные проблемы в инфраструктуре, так как требовал компиляции CSS. А еще Tailwind медленнее чем Restyle.

Отмели вариант с Tailwind:
❌ Tailwind

И у нас осталось на выбора всего 2 варианта: Restyle или StyleSheet.

Restyle VS StyleSheet

Пришло время вспомнить наши изначальные проблемы, ради чего все начиналось. Каждый вариант решает проблемы по-своему:

Здесь мы поняли, что StyleSheet без дополнительных оберток не решит вторую проблему. А если доработать этот вариант, то скорость рендера может увеличиться. Ведь мы делали замеры без всяких оберток. 

Дальше в таблице вы увидите уже доработанный вариант StyleSheet, а также обновленные замеры скорости рендера.

Финал

Мы сделали последнюю таблицу сравнений этих подходов, чтобы принять финальное решение:

Пример кода для StyleSheet

import {Text, View} from 'react-native';
import {
  Heading,
  Typography,
  Button,
  createStyleSheet,
  useStyleSheet
} from '@profi/uikit-rn';

const StyleSheetExample = ({ onPress }) => {
  const styles = useStyleSheet(stylesheet);
  return (
    
      
        Найдем любого профи - просто создайте заказ
      
      
        
          Создать заказ
        
      
    
  );
};

const stylesheet = createStyleSheet(
  theme => {
    return StyleSheet.create({
      container: {
          backgroundColor: theme.colors.g300,
          borderRadius: theme.radius.xl,
          padding: theme.space[4],
        },
        titleText: {
          marginBottom: theme.spaces[5],
          color: theme.colors.g500,
        },
        buttonText: {
          color: theme.colors.g100,
        },
    });
  },
);

Пример кода для Restyle

import {
  Box,
  Text,
  Button
} from '@profi/uikit-rn';

const RestyleExample = ({ onPress }) => {
  return (
    
      
        Найдем любого профи - просто создайте заказ
      
      
        
          Создать заказ
        
      
    
  );
};

Решение

Мы решили выбрать вариант со StyleSheet по следующим причинам:

• Решение простое и не требует больших трудозатрат на внедрение.

• Этот вариант работает быстрее Restyle.

• Будет гораздо легче переписать старые компоненты на этот вариант и полностью убрать styled-components из кода.

• Мы можем дорабатывать это решение по собственным требованиям.

• Такой вариант привычнее для разработки. Концепция кардинально не меняется (стили отдельно).

Моменты, которые смущали:

• Нужно тратить дополнительные усилия, чтобы научить всех использовать наше решение правильно (писать дополнительные документации, проводить обучающие митапы).

• Код выглядит слегка раздутым по сравнению с Restyle.

Выводы

По моим ощущениям, вариант со StyleSheet победил, потому что у нас уже написаны приложения. И переход со styled-components на StyleSheet кажется не таким болезненным, потому что концепция сильно не меняется.

При этом Restyle очень классно бы зашел для новых приложений, где такая архитектура будет закладываться изначально. Особенно, если разработчиков не смущают стили в атрибутах.

Но мы сошлись в одном, без всяких сомнений. Если ваше RN-приложение сложнее нескольких экранов, то styled-components — это вредная библиотека. И стоит от нее избавляться как можно раньше.

© Habrahabr.ru