MaterialUI отлично подходит… для небольших, личных или экспериментальных интерфейсных приложений. Но это кошмар, когда речь идет о больших масштабируемых приложениях. Если вы не уверены или вам интересно узнать о пользовательском интерфейсе материалов, вот мой отзыв о моем опыте.
Выбор правильной библиотеки пользовательского интерфейса (UI) для вашего проекта является важным решением. Одной из популярных UI-библиотек является Material UI, основанная на React библиотека готовых компонентов и инструментов для оформления. Хотя Material UI может быть мощным инструментом для быстрого создания веб-приложений, есть несколько причин, по которым разработчики, владельцы продуктов и технические директора должны избегать его в своих проектах.
Удобство использования и настройка
Отсутствие гибкости дизайна:
Язык дизайна Material UI основан на материальном дизайне Google, что может ограничить гибкость и креативность дизайна проекта.
Когда существует система дизайна, специфичная для проекта, использование Material UI означает, что разработчики должны «форсировать» другой язык дизайна вместо Material Design Google. Я обнаружил, что делаю это в некоторых проектах, и это не весело.
Кроме того, Material UI чрезмерно предписывает выбор дизайна, что приводит к отсутствию гибкости и адаптируемости для конкретных проектов. Разработчики могут столкнуться с необходимостью бороться с ограничениями Material UI, чтобы достичь желаемого дизайна и функциональности.
Однако вы можете использовать нестилизованные компоненты Material UI (MUI Base). Но другие предостережения этой библиотеки остаются проблемой.
Сложности с настройкой поведения компонентов
Одной из наиболее важных проблем с пользовательским интерфейсом материалов является его удобство использования и настройка. Несмотря на то, что библиотека предоставляет множество готовых компонентов, эти компоненты может быть сложно модифицировать в соответствии с конкретными потребностями проекта. Стили материального пользовательского интерфейса тесно связаны с его компонентами, что затрудняет их изменение, что приводит к дополнительным затратам времени на разработку и разочарованиям.
Например, чтобы внести сложные изменения в компоненты (например, сбросить вспомогательное поле ввода в форме), разработчикам необходимо иметь глубокие знания React, форм и глубокие знания о поведении MUI при передаче реквизитов, чтобы получить ref переданное вниз к вспомогательному входу. С более сложными компонентами, такими как таблицы и сетки данных, работать становится еще сложнее.
Мучительная поддержка типов для переопределений пользовательских тем/компонентов
При использовании библиотеки «как есть» проблем обычно не возникает. Но часто дизайн проекта существенно отличается от стилей MUI. В таких случаях структура темы должна быть расширена для включения новых свойств. Например, новые цвета, типографика, тени и т. д.
MUI позволяет это с помощью расширения модуля TypeScript, как описано в их Документации по настройке темы MUI. В теории неплохое решение. На практике ему не хватает поддержки, документации, а в некоторых случаях его очень сложно внедрить и поддерживать.
Слишком много способов переопределить стили
Еще одна проблема с пользовательским интерфейсом материалов — это множество способов стилизации компонентов. Разработчики могут использовать sx prop, style prop (встроенный стиль), className prop, переопределения реквизитов компонентов, глобальные переопределения темы, глобальное переопределение CSS, переопределение реквизитов, стили эмоций и многое другое. Это может затруднить поддержание согласованного языка дизайна и привести к несоответствиям между различными частями пользовательского интерфейса. Также нет никаких стандартов относительно того, какой метод укладки использовать. Изменение стилей становится кошмаром, когда переопределения стилей разбросаны по кодовой базе.
Решение может состоять в том, чтобы придерживаться только одного метода переопределения стиля.
Был там, сделал это.
Скорее всего, вы в конечном итоге смешаете их из-за ограничений одного подхода по сравнению с другим.
Обслуживание, обновления и поддержка
Значительные технические долги после крупных обновлений
MUI имеет опыт внесения значительных изменений в основные версии (например, v3 => v4, v4 => v5, v5 => v6 (?)) с критическими изменениями, которые очень трудно исправить или отнять много времени. Из-за этого обновление библиотеки становится менее вероятным и со временем создает огромный технический долг для масштабируемых приложений.
См.:
Миграция ядра
- https://mui.com/material-ui/migration/migration-v3/ (V3 => V4)
- https://mui.com/material-ui/migration/migration-v4/ (V4 => V5)
MUI X Migration
- https://mui.com/x/migration/migration-data-grid-v4/ (V4 =› V5)
— https://mui.com/x/ migration/migration-pickers-lab/ (Lab =› V5)
- https://mui.com/x/migration/migration-data -grid-v5/ (V5 => V6)
- https://mui.com/x/migration/migration-pickers-v5/ (V5 => V6)
🤞🏻 … Удачи!
«Лабораторные» компоненты
Лабораторные компоненты — это инкубационные компоненты, которые еще не готовы к переходу в основной пакет. Их использование потребует регулярного обслуживания (проверка/обновление/исправление критических изменений). Пример: DateTimePicker (перенесенный в MUI X) и LoadingButton, и это лишь некоторые из них.
Некоторые из этих компонентов попадают в MUI X, для которого требуется специальная платная коммерческая лицензия. Это означает, что если ваш проект зависит от них, вам нужно будет заплатить за лицензию MUI X или вам придется переписать большую часть своего кода, чтобы заменить эти компоненты!
Получение поддержки — непростая задача.
Если вам не очень повезло, независимо от того, насколько вы хороший разработчик, вы столкнетесь с проблемами при работе с Material UI.
Так что вы пойдете в StackOverflow или сделаете поиск в Google, чтобы найти ответы (все так делают!). Сюрприз-сюрприз…либо:
- Нет ответов на вашу конкретную ситуацию, потому что вы используете последнюю версию, и не так много людей уже столкнулись с этой проблемой или;
- Сообщения StackOverflow/Blog пользовательского интерфейса старых материалов наводнили Интернет, предоставляя неактуальные ответы, нацеленные на более ранние неподдерживаемые версии, такие как v3 и v4.
Итак, вы создаете новый вопрос StackOverflow, на который никогда не получите ответов, если только вам не повезет, как я уже говорил 😉
Или тратьте часы и часы, пока, наконец, не найдете решение… или сдайтесь.
Доступность и совместимость
Поддержка ограниченного доступа
Хотя Material UI предоставляет некоторые специальные возможности, он не полностью соответствует стандартам специальных возможностей, таким как WCAG 2.1. Это может затруднить разработчикам обеспечение полной доступности их проектов для пользователей с ограниченными возможностями.
Проблемы с совместимостью браузера
Пользовательский интерфейс материалов работает в большинстве браузеров; это плохо их поддерживает. Например, в Safari есть некоторые проблемы со стилем, что может привести к непоследовательному взаимодействию с пользователем.
Заключение
MaterialUI — отличный выбор для очень маленьких/личных проектов. Но, вероятно, есть лучший выбор для вашего масштабируемого внешнего интерфейса.
Если вы столкнулись с руководителями проектов, владельцами продуктов, консультантами или техническими директорами, которые считают иначе, поделитесь с ними этой публикацией… или просто добавьте ссылку на эту публикацию в свой билет Tech Debt 😉
Поделитесь своими мыслями или опытом работы с Material UI в комментариях ниже! Не забудьте👏🏻 если вам понравилась эта история.
Удачного кодирования 🚀
Вам также может понравиться…
Дополнительные материалы на PlainEnglish.io.
Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .
