Комментарии 13
Cпасибо за статью
А почему решили писать собственный мемоизатор для функции создания стилей?
Мы просто пришли к такому коду, ну и в целом стараемся юзать встроенную мемоизацию.
const useStyleSheet = <T>(creator: StyleSheetCreator<T>): T => {
const { theme } = useTheme();
return useMemo(() => creator(theme), [theme, creator]);
};
Ну и использование вида
const styles = useStyleSheet(styleSheetCreator);
Я в статье как раз пишу в пункте 2.2, что в вашем случае стили создаются каждым компонентом, что плохо влияет на производительность. В моем случае они переиспользуются всеми компонентами, и нет дополнительного useMemo. Также в вашем случае я вижу придется еще и creator в useCallback заворачивать, либо выносить из компонента.
И еще вопрос - а при использовании getStyle все равно работает определение неиспользуемых стилей?
По поводу размеров отступов - мы пришли к тому, что лучше делать таки по сетке в 4 пикселя.
Дело не в том, что мы что-то собираемся поменять потом, это техника безопасности при ошибках в макетах - то есть, если мы видим какой-то нестандартный отступ между - сразу понятно - это баг
Ну и дальше можно стандартизовать еще какое-то количество отступов семантически , что удобно в продуктовой разрабокте, когда надо постоянно изменять фичи.
Очень часто бывает, что чтобы сделать pixel perfect интерфейс, отступы в коде должны немного отличаться от макетов из за мелких отличий того или иного встроенного компонента, шрифта или экспортированной картинки.
Также, не помню чтоб была проблема нестандартных отступов там где не нужно - действительно ли она существует чтоб ее решать?
Если же речь идет о 100% одинаковом отступе для компонентов на одном экране, например схожие но разные ячейки, то конечно иногда имеет смысл вынести его в константу, а то и экспортировать общие стили, сам так много раз делал. Добавлю это в статью.
Но спасибо за мнение.
Тут скорее речь о кросс-проектной семантики отступов - чтобы определенные типы отступов были всегда одинаковые, или там - кастомные заданные варианты line height к определенным размерам шрифта (правда это мы решили просто своим компонентом для текста с типированными параметрами, а не константами).
То есть это про общую консистентность дизайна в проекте.
Кстати - а чем вы пользуетесь для Pixel Perfect на RN? Я одно время просил дизайнеров в Zeplin выгружать, чтобы был полупрозрачный слой, но чет не прижилась практика.
Когда то давно помню накладывал полупрозрачные картинки поверх симуляторов - для мака какой то плагин был даже чтобы для любого окна можно было поменять прозрачность.
Но последнее время если прям точно надо (что бывает редко), то делаю скриншот с симулятора / эмулятора и в Preview замеряю отступ с помощью выделения. По возможности стараюсь делегировать это на отдел тестирования.
У нас все макеты в фигме и сделаны для размера экрана iPhone 11 Pro.
Когда делаю верстку, то юзаю этот симулятор либо схожий по размерам(width,height).
В результате я фигме я выгружаю экран в отдельный таб, где мне доступны разные инструменты, в том числе линейка(вертикальная/горизонтальная).
Затем делаю скоиншот экрана симулятора и вставляю рядом с дизайнерским экраном.
Инструментом линейки я создаю прямые у ui элементов(слева/справа/сверху/снизу) на эталоном экране и сверяю, что элементы на моем скриншоте находятся на этой прямой.
Немного геморно, но вариант рабочий.
Добавлю ссылочку на более свежий бенчмарк и версии библиотек https://github.com/divineniiquaye/react-native-style-libraries-benchmark
С недавнего времени используем unistyles.
По замерам они не сильно отстают от "голых" stylesheets, но добавляют удобный инструментарий для предоставления темы, в том числе для работы со шрифтами.
Впечатления пока очень хорошие.
Стили, темы и адаптивная верстка в React Native