Material-ui: Используйте стилизованные компоненты во всех демонстрациях

@oliviertassinari what is the exactly the tasks in hand? @oliviertassinari , какие именно задачи стоят перед вами?

Here is what I understand, Вот что я понимаю,

1. Run the docs website Запустите веб-сайт документации
2. Find all the example source code that uses material-ui/styles Найдите весь пример исходного кода, в котором используется material-ui/styles
3. Replace them with styled-components Замените их на styled-components

Is this correct? Это верно?

@yordis I think that the timing is going to be key in this transition. @yordis Я думаю, что время будет ключевым в этом переходе. I would imagine the following steps: Я бы представил следующие шаги:

1. We replace the usage of @material-ui/styles in the demos with the Box component, where possible. Мы заменили использование @material-ui/styles в демонстрациях компонентом Box, где это возможно. Moving #16858 at the same time would help. Одновременное перемещение #16858 помогло бы. This can be done in the near future. Это можно сделать в ближайшее время.
2. We solve #15561, we migrate more demos away from @material-ui/styles to use the system props. Мы решаем #15561, мы переносим больше демо из @material-ui/styles, чтобы использовать системные реквизиты. The sooner we solve this, the better. Чем раньше мы это решим, тем лучше.
3. We update the customization demos to use styled-components, leveraging the global Mui class names. Мы обновляем демонстрации настройки, чтобы использовать стилизованные компоненты, используя глобальные имена классов Mui. We might need to work on some helpers to make accessing the theme values easier. Возможно, нам придется поработать над некоторыми помощниками, чтобы упростить доступ к значениям темы.
4. We solve #6115, we migrate the last usages of @material-ui/styles to styled-components. Решаем #6115, переносим последние использования @material-ui/styles в styled-components. This is a task for v5, I think that we can start it Q1 2020 in the v5 alpha/beta versions. Это задача для v5, я думаю, что мы можем начать ее в первом квартале 2020 года в версиях v5 alpha/beta.

@oliviertassinari Мне любопытно, и я извиняюсь, если это повторилось: почему бы не сохранить @material-ui/styles в качестве оболочки или абстракции для styled-components ?

@ConAntonakos it's an option. @ConAntonakos это вариант. It could help if we need to extend/normalize some of the features of styled-components. Это может помочь, если нам нужно расширить/нормализовать некоторые функции styled-components.

@oliviertassinari у нас есть список того, что осталось?

@yordis We haven't done many efforts in this direction yet. @yordis Мы еще не приложили много усилий в этом направлении. However, there is a probability that it will require breaking changes, v5 is planned for around Q4 2020. I think that we should explore a partial deployment strategy for developers that want to leverage it sooner. Однако есть вероятность, что для этого потребуются критические изменения, версия 5 запланирована примерно на четвертый квартал 2020 года. Я думаю, что нам следует изучить стратегию частичного развертывания для разработчиков, которые хотят использовать ее раньше. Now, this effort has to be balanced with the other priorities, like the support of new advanced components (free and paid) or the release of an unstyled version of the library to increase our audience reach (with different themes, eg iOS style). Теперь эти усилия должны быть сбалансированы с другими приоритетами, такими как поддержка новых расширенных компонентов (бесплатных и платных) или выпуск нестилизованной версии библиотеки для увеличения охвата нашей аудитории (с различными темами, например, в стиле iOS). The good news is that we will likely grow the team in the coming months, enabling us to move faster. Хорошая новость заключается в том, что в ближайшие месяцы мы, скорее всего, расширим команду, что позволит нам двигаться быстрее.

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles ). Я предполагаю, что сегодня вы уже используете styled-components поверх Material-UI, как это делают многие другие разработчики (а не @material-ui/styles ). What are the top pain points you hope to address with this migration? Каковы основные болевые точки, которые вы надеетесь решить с помощью этой миграции?

From a product perspective, our incentive is about: smaller bundle size, better performance, steaming support, fewer bugs, CSS template strings support, larger community, enables to use the system props in the core components, allow true dynamic themes and props support, better docs. С точки зрения продукта, наш стимул заключается в следующем: меньший размер пакета, лучшая производительность, поддержка паровой обработки, меньшее количество ошибок, поддержка строк шаблонов CSS, более широкое сообщество, возможность использовать системные реквизиты в основных компонентах, обеспечить настоящую динамическую поддержку тем и реквизитов, лучшие документы.

However, there is a high probability that it will require breaking changes, Однако есть большая вероятность, что для этого потребуются критические изменения,

Yeah, I tried to change some examples, but they require some integration with the theme provider, so we may need to inject material/style theme provider and styled-component theme provider I am assuming. Да, я пытался изменить некоторые примеры, но они требуют некоторой интеграции с провайдером тем, поэтому нам может понадобиться внедрить провайдера тем material/style и провайдера тем styled-component , как я предполагаю.

v5 is planned for around Q4 2020. v5 запланирован примерно на четвертый квартал 2020 года.

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment? Этого достаточно, не лучше ли связать разные вопросы для наглядности с тем, что является приоритетным на данный момент?

I imagine you are already using styled-components on top of Material-UI today as many other developers do (and not @material-ui/styles). Я предполагаю, что сегодня вы уже используете styled-components поверх Material-UI, как и многие другие разработчики (а не @material-ui/styles).

Actually, I am quite happy with @material-ui/styles and I am not using styled-components when I use Material UI (I would remove withStyles since I don't want to rely on programmer discipline 😉 , but I understand legacy software may no have hooks still )🤷‍♂️ На самом деле, я вполне доволен @material-ui/styles и не использую styled-components , когда использую Material UI (я бы удалил withStyles , так как не хочу полагаться на дисциплину программиста). 😉 , но я понимаю, что в старом софте хуков может и не быть )🤷‍♂️

What are the top pain points you hope to address with this migration? Каковы основные болевые точки, которые вы надеетесь решить с помощью этой миграции?

I am trying to help with the migration, personally, no pain points. Я пытаюсь помочь с миграцией, лично я не болен. Unless you take into consideration that as an ecosystem, I have to maintain two ways to develop something, but meh, personally, it is okay for me. Если не принимать во внимание, что как экосистема, я должен поддерживать два способа разработки чего-то, но лично для меня это нормально.

Maybe styled-components fixes some interoperability with NextJS and Gatsby since the last time I tried was hard to make Mui work with those tools because of the SSR and styles (I am not sure if still painful) and most libraries using styled-components work out of the box. Возможно, styled-components исправляет некоторую совместимость с NextJS и Gatsby, поскольку в последний раз, когда я пытался заставить Mui работать с этими инструментами, было сложно из-за SSR и стилей (я не уверен, что все еще болезненно) и большинства библиотек, использующих styled-components работает из коробки.

Let me know how I could help, like I said, I was using the pinned issues to find the prioritization of the Org Дайте мне знать, как я могу помочь, как я уже сказал, я использовал закрепленные проблемы, чтобы найти приоритеты организации.

That is far enough, would it be better to pin different issues for visibility on what is a priority at the moment? Этого достаточно, не лучше ли связать разные вопросы для наглядности с тем, что является приоритетным на данный момент?

It depends on the time horizon you are interested in. You can follow the issue with the label important , the roadmap page on the documentation and the monthly blog product updates. Это зависит от интересующего вас временного горизонта. Вы можете следить за проблемой с меткой important , страницей дорожной карты в документации и ежемесячными обновлениями продукта в блоге.

I don't fully understand this point. Я не совсем понимаю этот момент. Why not using styled-components when using Material-UI (today)? Почему бы не использовать стилизованные компоненты при использовании Material-UI (сегодня)? We had 1/3 of our users going down this path when we did our last survey, 6 months ago. 1/3 наших пользователей пошли по этому пути, когда мы проводили наш последний опрос 6 месяцев назад.

I don't fully understand this point. Я не совсем понимаю этот момент. Why not using styled-components when using Material-UI (today)? Почему бы не использовать стилизованные компоненты при использовании Material-UI (сегодня)?

@material-ui/styles works like a champ so far, no reason to migrate everything 😄 so I am one of those out of 3 that don't use it together today. @material-ui/styles пока работает как чемпион, нет причин все переносить 😄 так что я один из тех 3, кто не использует его вместе сегодня.

Thank you for the info about prioritization. Спасибо за информацию о расстановке приоритетов.

@yordis btw, my answer was made under the assumption you were following up on the main styled-components issue. @yordis кстати, мой ответ был сделан исходя из предположения, что вы занимаетесь основной проблемой стилевых компонентов. I haven't realized we were on the documentation one. Я не понял, что мы были на документации один.

@oliviertassinari do you have any suggestions about the issue with theme context? @oliviertassinari у вас есть предложения по поводу проблемы с контекстом темы?

I tried to use props.theme inside an styled-components but didn't work, I am not sure if you have a suggestion for it, but I think we will require to add styled-components theme provider as well. Я пытался использовать props.theme внутри styled-components , но это не сработало, я не уверен, что у вас есть предложения по этому поводу, но я думаю, что нам потребуется добавить styled-components поставщик тем.

Hey @oliviertassinari! Привет, @oliviertassinari! Are you looking for PR's that convert the existing customization demos to use styled-components as part of this issue? Вы ищете PR, которые преобразуют существующие демонстрации настройки для использования стилизованных компонентов в рамках этой проблемы?

I dont think styled-components is a good styling solution. Я не думаю, что styled-components — хорошее решение для стиля. current solution looks much much more readable, appealing, accessible and cleaner than styled. текущее решение выглядит гораздо более читабельным, привлекательным, доступным и чистым, чем стилизованное. i dont see any good reason to migrate. я не вижу веских причин для миграции.

I dont think styled-components is a good styling solution. Я не думаю, что styled-components — хорошее решение для стиля. current solution looks much much more readable, appealing, accessible and cleaner than styled. текущее решение выглядит гораздо более читабельным, привлекательным, доступным и чистым, чем стилизованное. i dont see any good reason to migrate. я не вижу веских причин для миграции.

And get almost fully typed. И получить почти полностью типизированный. Don't see any reason to migrate +1 Не вижу причин для переноса +1

The link you've posted, that should show growing interest to styled-components, recently started showing a downward trend: Опубликованная вами ссылка , которая должна показать растущий интерес к styled-components, недавно начала показывать тенденцию к снижению:

I feel that narrowing down a styling solution to a single library is going to give us the exact same problem as we have today. Я чувствую, что сужение решения по стилю до одной библиотеки даст нам ту же проблему, что и сегодня.

What about integration with zero-runtime libraries such as linaria ? Как насчет интеграции с библиотеками нулевого времени выполнения, такими как linaria ? This was suggested as being looked at in May 2019 Update . Это было предложено для рассмотрения в May 2019 Update .

So far it only recovered to pre-v5-hype. Пока что он восстановился только до ажиотажа до v5. Let's see how the updated data point for January till now looks. Давайте посмотрим, как выглядят обновленные данные за январь до сих пор.

@TheHolyWaffle Don't trust rank2traffic.com too much, data hasn't been very reliable nor up-to-date, its main advantage was the overall trend over 10 years (before it was made paid). @TheHolyWaffle Не слишком доверяйте rank2traffic.com, данные не были очень надежными и неактуальными, его главным преимуществом была общая тенденция за 10 лет (до того, как он стал платным). For a shorter time window, so 6 months, prefer https://www.similarweb.com/ as more reliable. Для более короткого временного окна, например, 6 месяцев, предпочтительнее https://www.similarweb.com/ как более надежный.
Also take into account that once people know the API, they come back much frequently to the documentation. Также примите во внимание, что как только люди узнают об API, они будут часто возвращаться к документации.

I dont think styled-components is a good styling solution. Я не думаю, что styled-components — хорошее решение для стиля. current solution looks much much more readable, appealing, accessible and cleaner than styled. текущее решение выглядит гораздо более читабельным, привлекательным, доступным и чистым, чем стилизованное. i dont see any good reason to migrate. я не вижу веских причин для миграции.

And get almost fully typed. И получить почти полностью типизированный. Don't see any reason to migrate +1 Не вижу причин для переноса +1

+1 styles is the main reason we're migrating to Material UI and moving away from styled components. +1 styles — основная причина, по которой мы переходим на Material UI и отказываемся от стилизованных компонентов. It's too much CSS and refactoring it has proven to be a huge burden for us. Это слишком много CSS, и его рефакторинг оказался для нас огромным бременем.

Hi! Привет! First of all, thank you for providing a great component library, best one I've used so far. Прежде всего, спасибо за предоставление отличной библиотеки компонентов, лучшей из тех, что я использовал до сих пор. Our teams have written hundreds of thousands of lines of code using the components and methodology you created and once developers learn the basics of using classes , how to write the styles etc., it's a breeze to work with even on a massive enterprise scale type of codebase. Наши команды написали сотни тысяч строк кода, используя созданные вами компоненты и методологию, и как только разработчики изучат основы использования classes , как писать стили и т. д., с ними будет легко работать даже на кодовая база массивного масштаба предприятия.

I'm not sure if that's the most common use of your library, but I suppose you are aware that many teams build their component libraries on top of Material UI, and so any components and decision you make also trickle down to those libraries. Я не уверен, что это наиболее распространенное использование вашей библиотеки, но я полагаю, вы знаете, что многие команды создают свои библиотеки компонентов поверх Material UI, и поэтому любые компоненты и решения, которые вы принимаете, также просачиваются в эти библиотеки. On our end we've been very happy with both performance and APIs so far. С нашей стороны, мы пока очень довольны как производительностью, так и API.

I've been following recent development in the library and to be honest, I'm having trouble understanding some of the decisions and worried how that will affect our teams, and what's overall the benefit of this move would be, as opposed to for example forking MUI. Я следил за последними разработками в библиотеке и, честно говоря, у меня возникли проблемы с пониманием некоторых решений, и я беспокоюсь, как это повлияет на наши команды, и какова общая польза от этого шага, в отличие от, например, разветвление MUI. Others have voiced their concern about move to styled components so I'll focus on the other one for me - the Box component. Другие выразили обеспокоенность по поводу перехода на стилизованные компоненты, поэтому я сосредоточусь на другом для себя — компоненте Box.

I understand the utility of a Box component - to make it possible to use theme variables etc. in prop values, however the API and the consequences of using this component disqualify it from something I could recommend to our teams. Я понимаю полезность компонента Box — чтобы можно было использовать переменные темы и т. д. в значениях свойств, однако API и последствия использования этого компонента лишают его права на то, что я мог бы порекомендовать нашим командам.

First , it has a cryptic API for no reason I can discern (unless saving a few bytes is that reason): Instead of writing <Box margin={3} /> , it would be <Box m={3} /> . Во- первых , у него загадочный API по непонятной мне причине (если только не экономия нескольких байтов): вместо <Box margin={3} /> будет <Box m={3} /> .

Abbreviations like that seem needless, make things potentially ambigious, and introdue a new learning curve to developers, a mapping of abbreviations to actual properties they now need to memorize: "Is applying color done using c or color ?", "Is background a b , or bg , or background , or was b a border ?" Подобные аббревиатуры кажутся ненужными, делают вещи потенциально двусмысленными и вводят новую кривую обучения для разработчиков, сопоставление аббревиатур с фактическими свойствами, которые им теперь нужно запомнить: «Применение color выполняется с использованием c или color ?", "Является ли background b , или bg , или background , или было b border ?" "Is background-size abbreviated as bs ?" " background-size сокращенно выглядит как bs ?"

Second , components abstract most commonly recurring UI patterns, and create APIs that provide means of customizing those patterns to the extent that the design system permits. Во- вторых , компоненты абстрагируются от наиболее часто повторяющихся шаблонов пользовательского интерфейса и создают API-интерфейсы, предоставляющие средства настройки этих шаблонов в той мере, в какой это позволяет система дизайна. This manifests in creating props like gutterBottom on Typography , or dense on ListItem - as opposed to accepting just about any padding or margin. Это проявляется в создании таких реквизитов, как gutterBottom на Typography или dense на ListItem — в отличие от принятия практически любых отступов или полей. I feel like introducing Box to large extent undermines this effort and introduces a tool that will make a mess out of any attempt to follow a design system unless we define some very nitpicky ways that Box component can be used for and spend effort in code reviews to make sure the all the values in used Box props aren't beyond the accepted list. Я чувствую, что введение Box в значительной степени подрывает эти усилия и представляет инструмент, который превратит в беспорядок любую попытку следовать системе дизайна, если мы не определим некоторые очень придирчивые способы использования компонента Box и его расходования. усилия по проверке кода, чтобы убедиться, что все значения в используемых свойствах Box не выходят за рамки допустимого списка. And at that point, the way to "automate" this would be to create a component that restricts the options, and we're backt to square one. И в этот момент способ «автоматизировать» это будет заключаться в создании компонента, который ограничивает параметры, и мы возвращаемся к исходной точке. To give an example, why would using Box mb={2} to achieve margin under Typography be okay, but Box mb={6} not? Например, почему использование Box mb={2} для достижения маржи в соответствии с типографикой допустимо, а Box mb={6} нет? This concern doesn't exist when we can rely on props to limit the options. Этого беспокойства не существует, когда мы можем полагаться на реквизиты для ограничения вариантов.

Third concern, or rather a question I have. Третье беспокойство, вернее вопрос у меня. Since the Box component is potentially a quick way to build certain functionality, it would be also used by libraries built on top of MUI. Поскольку компонент Box потенциально является быстрым способом создания определенных функций, он также будет использоваться библиотеками, созданными поверх MUI. How would one override the styles of Box components used within another component? Как переопределить стили компонентов Box , используемых в другом компоненте? As an example. Например. If we built ListItem using Box under the hood, would we need to introduce BoxProps={{ padding: 2 }} , or accept also dense prop based on which we write logic to apply a padding prop to a particular Box, or still something else? Если бы мы построили ListItem, используя Box под капотом, нам нужно было бы ввести BoxProps={{ padding: 2 }} или принять также свойство dense , на основе которого мы пишем логику для применения свойства padding к конкретный Box, или еще что-то?

I'm not sure if that's the most common use of your library, but I suppose you are aware that many teams build their component libraries on top of Material UI , and so any components and decision you make also trickle down to those libraries. Я не уверен, что это наиболее распространенное использование вашей библиотеки, но я полагаю, вы знаете, что многие команды создают свои библиотеки компонентов поверх Material UI , и поэтому любые компоненты и решения, которые вы принимаете, также просачиваются в эти библиотеки. On our end we've been very happy with both performance and APIs so far. С нашей стороны, мы пока очень довольны как производительностью, так и API.

@maciej-gurban This use case is an important one for us. @maciej-gurban Этот вариант использования важен для нас. Our incentives are aligned to significantly improve it. Наши стимулы выровнены, чтобы значительно улучшить его. This is one of our objectives with v5. Это одна из наших целей с v5.

For instance, we are investigating the feasibility to provide a design tool that could be put in the hands of designers (paid) and would output ready to use customized Material-UI components (MIT), corresponding documentation, Sketch & Figma kit. Например, мы изучаем возможность предоставления инструмента проектирования, который можно было бы передать в руки дизайнеров (платно) и который будет выводить готовые к использованию настраиваемые компоненты Material-UI (MIT), соответствующую документацию, набор Sketch & Figma. Basically, all we have been going it for Material Design but scaling it 🚀. По сути, все, что мы делаем, это Material Design, но масштабируем его 🚀.
The end goal here would be to free the time of a couple of front-end developers in each company. Конечной целью здесь будет высвобождение времени пары фронтенд-разработчиков в каждой компании. Why have front-end developers build a custom design system when it can be done by your own designers + Material-UI at a fraction of the cost? Зачем фронтенд-разработчикам создавать индивидуальную систему дизайна, если это могут сделать ваши собственные дизайнеры + Material-UI за небольшую часть стоимости? + reduce risk and have your front-end developers spend time where they make the most differences: working on the product. + уменьшите риск и позвольте вашим фронтенд-разработчикам посвятить время тому, что приносит наибольшую пользу: работе над продуктом.

I'm having trouble understanding some of the decisions and worried how that will affect our teams Мне трудно понять некоторые решения, и я беспокоюсь, как это повлияет на наши команды.

If you could list them, it would be awesome. Если бы вы могли их перечислить, было бы здорово.

Others have voiced their concern about move to styled components Другие выразили обеспокоенность по поводу перехода на стилизованные компоненты.

What's your concern with such a shift? Что вас беспокоит в таком сдвиге? Our objective on the styling side has a couple of layer: Наша цель на стороне стиля состоит из нескольких слоев:

1. Unstyled component, expose the same existing components but without any styles. Компонент без стилей, предоставляющий доступ к тем же существующим компонентам, но без каких-либо стилей. Keep the same classes API (first seen in jQuery-UI), provide default hardcoded values for each of the classes (global class names). Сохраните тот же API classes (впервые появившийся в jQuery-UI), предоставьте жестко закодированные значения по умолчанию для каждого из классов (глобальные имена классов). The objective behind this shift answer to a couple of incentives. Цель этого сдвига ответить на несколько стимулов. First, it's to dismiss a fear our users have, same to CRA eject mode, you won't use it but it feels safe to be present. Во-первых, это избавление от опасений наших пользователей, как и в случае с режимом извлечения CRA, вы не будете его использовать, но присутствие в нем кажется безопасным. Second, it's required to be able to build the paid design tool. Во-вторых, необходимо уметь создавать платный инструмент дизайна. Third, it's required for the next layer В-третьих, это требуется для следующего слоя
2. Multiple style engines. Двигатели нескольких стилей. The community is fragmented between different styling approaches. Сообщество фрагментировано между различными подходами к стилю. By order of popularity: styled-components, plain CSS, CSS modules, emotion, JSS, utility first classes. В порядке популярности: стилизованные компоненты, простой CSS, CSS-модули, эмоции, JSS, служебные первые классы. It still feels like we didn't find the holy grail for styling. Все еще кажется, что мы не нашли святой Грааль для стиля. And until we do, better not bet too much on any styling solution. И пока мы этого не сделаем, лучше не ставить слишком много на какое-либо решение для укладки. So, have styled-components has the default, but allow developers to switch engine, stay on JSS if they are happy too. Таким образом, styled-components имеет значение по умолчанию, но позволяет разработчикам переключать движок, оставаясь на JSS, если они тоже довольны.
3. Baseline theme. Базовая тема. Something less opinionated than the current default Material Desing Theme, but using the same theme's specification. Что-то менее самоуверенное, чем текущая тема оформления материалов по умолчанию, но использующая ту же спецификацию темы.
4. A couple of different themes on top of the baseline. Несколько разных тем поверх базовой линии. One for marketing pages, One for the Chinese market (close to the Gmail equivalent of China). Один для маркетинговых страниц, один для китайского рынка (близко к китайскому эквиваленту Gmail).

I'll focus on the other one for me - the Box component. Я сосредоточусь на другом для меня — компоненте Box.

Yeah, I can hear you! Да, я слышу тебя! I have been working with @gregberge in the past. Я работал с @gregberge в прошлом. At some point, we have considered hiding all the className props on @doctolib 's design system. В какой-то момент мы подумали о том, чтобы скрыть все реквизиты className в дизайн-системе @doctolib. The interesting thought is that you can gain features (properties) in exchange of more constraints. Интересная мысль заключается в том, что вы можете получить функции (свойства) в обмен на большее количество ограничений.

I wouldn't worry too much about this one. Я бы не стал слишком беспокоиться об этом. This can be resolved with a global option to limit the access to the "system"'s features or an eslint rule. Это можно решить с помощью глобальной опции для ограничения доступа к «системным» функциям или правила eslint.

The abbreviation on the Box component is confusing. Аббревиатура компонента Box сбивает с толку. Code is being read more than being written, so it's important to keep clear what the code is meaning. Код чаще читают, чем пишут, поэтому важно четко понимать, что он означает. Last day I found "Box py={2}" in our codebase and I'm totally confused. Вчера я нашел «Box py={2}» в нашей кодовой базе и совершенно запутался. After a search I figured out that means "paddingY". После поиска я понял, что это означает «paddingY». Those abbreviation should not be encouraged especially non-css properties (I can guess pt means padding-top but not for py) Эти аббревиатуры не следует поощрять, особенно свойства, отличные от CSS (я могу предположить, что pt означает padding-top, но не для py)

@oliviertassinari Thanks for your patience @oliviertassinari Спасибо за терпение

I'm having trouble understanding some of the decisions and worried how that will affect our teams Мне трудно понять некоторые решения, и я беспокоюсь, как это повлияет на наши команды.

If you could list them, it would be awesome. Если бы вы могли их перечислить, было бы здорово.

I wouldn't want this to turn into a litany of things I disagree with, because ultimately you're the guys who maintain this library and our view of what makes sense will be shaped by our own needs which might and likely don't always align, and that's fine. Я бы не хотел, чтобы это превратилось в список вещей, с которыми я не согласен, потому что, в конечном счете, именно вы поддерживаете эту библиотеку, и наше представление о том, что имеет смысл, будет формироваться нашими собственными потребностями, которые могут и, вероятно, не всегда выровнять, и ладно. I'm not against introducing the means of using other styling solutions - in fact I think it's great as it will bring more users who were holding off because of their dislike for JSS, but there's also us - the already existing users of your library who are sold on your solution, and if possible, would like to avoid massive refactor. Я не против введения средств использования других стилевых решений - на самом деле я думаю, что это здорово, поскольку это привлечет больше пользователей, которые откладывали из-за своей неприязни к JSS, но есть и мы - уже существующие пользователи вашей библиотеки, которые продаются за ваше решение, и, если возможно, хотели бы избежать массового рефакторинга.

Even if you decide that "we still provide support for JSS", refactoring all demos and your components to styled components will force the teams using JSS to migrate to styled components. Даже если вы решите, что «мы по-прежнему предоставляем поддержку JSS», рефакторинг всех демонстраций и ваших компонентов в стилизованные компоненты заставит команды, использующие JSS, перейти на стилизованные компоненты. "Why are we still using X, when MUI team moved to Y?" «Почему мы все еще используем X, когда команда MUI перешла на Y?» - will be one of the many questions in light of which it would be really hard not to agree with needing to make that migration sooner or later. - будет одним из многих вопросов, в свете которых было бы действительно трудно не согласиться с необходимостью сделать эту миграцию рано или поздно.

I can definitely empathize with wanting to reach a wider audience by using a styling solution that's more popular. Я определенно могу сочувствовать желанию охватить более широкую аудиторию, используя более популярное решение для стиля. However, I think it's worth considering that "popular" is not always "best" and that a move to a different tech needs onsideration not only of advantages and disadvantages of both solution, but the context in which we're making the decision. Тем не менее, я думаю, стоит учитывать, что «популярное» не всегда «лучшее» и что переход на другую технологию требует рассмотрения не только преимуществ и недостатков обоих решений, но и контекста, в котором мы принимаем решение.

Starting fresh, looking merely at advantages of X over Y makes sense, but working on an already existing system we also need to consider the cost of switching over and domino effects this bring on downstream teams. Начинать с чистого листа, просто рассматривая преимущества X над Y, имеет смысл, но, работая с уже существующей системой, мы также должны учитывать стоимость перехода и эффект домино, который это повлечет за собой последующие команды. For this switch over to make sense the advantanges of the other solution need to outweight the cost of migrating over. Чтобы этот переход имел смысл, преимущества другого решения должны перевесить стоимость перехода. It seems that for your team, that cost benefit analysis rules in favor of styled components, but from what I can tell looking at reactions at posts talking about styled components in your repo, your user base is far from the same conclusion. Похоже, что для вашей команды анализ затрат и выгод дает преимущество стилизованным компонентам, но, судя по реакции на сообщения о стилизованных компонентах в вашем репозитории, ваша пользовательская база далека от того же вывода.

Like you said, your aim is to open up MUI to more styling solutions. Как вы сказали, ваша цель — открыть MUI для большего количества стилевых решений. To provide good support for those solutions, there would need to be good documentation, examples and smooth integration layer - otherwise developers would find it hard to translate what they see in demos into what their styling solution of choice needs. Чтобы обеспечить хорошую поддержку этих решений, должна быть хорошая документация, примеры и плавный уровень интеграции — иначе разработчикам будет трудно преобразовать то, что они видят в демонстрациях, в то, что нужно их выбранному решению по стилю. I'm just not sure if you really need to migrate to styled components to achieve the goals. Я просто не уверен, действительно ли вам нужно переходить на стилизованные компоненты для достижения целей. Seems like your solution is also perfectly capable, if not more so than others, to build the design tool you're after since you already use actual JS object for all the styles. Похоже, что ваше решение также отлично подходит, если не больше, чем другие, для создания инструмента дизайна, который вам нужен, поскольку вы уже используете фактический объект JS для всех стилей.

One question I have, does this mean that the core of Mui would still use jss, and this allows for a better way to use styled components on top of that? У меня есть один вопрос: означает ли это, что ядро ​​Mui по-прежнему будет использовать jss, и это позволит лучше использовать стилизованные компоненты? Or would there be a way to say the core is also styled? Или можно было бы сказать, что ядро ​​также стилизовано? I just think it would add a lot of bloat if you have two css in js solutions. Я просто думаю, что это добавит много раздувания, если у вас есть два решения css в js.

How would theming work if using styled-components? Как будет работать тематика при использовании стилизованных компонентов? I used to use helpers in the CSS portion, and it was really messy. Раньше я использовал помощники в части CSS, и это было очень грязно. For me, the approach of applying theme props in a JS object is a lot cleaner than in a templated string. Для меня подход применения реквизитов темы в объекте JS намного чище, чем в шаблонной строке.

For me (scientific backend programmer by origin), MUI styles bring beautiful, calming, predictable, parameterisable logic to the mental, crazy, bonkers-rules why-the-hell tearing-hair-out world of CSS. Для меня (по происхождению ученого программиста бэкенда) стили MUI привносят красивую, успокаивающую, предсказуемую, параметризуемую логику в ментальный, сумасшедший, безумный мир правил CSS, который, черт возьми, рвет на себе волосы.

The styles library (and its tight integration with the theme) is the main reason I mandate use of MUI over any other components library in the two organisations I oversee tech for - it takes all the css agony away! Библиотека стилей (и ее тесная интеграция с темой) — главная причина, по которой я предписываю использовать MUI по сравнению с любой другой библиотекой компонентов в двух организациях, для которых я наблюдаю за технологиями — это снимает всю агонию css! At first, all the developers I work with are like "what the hell's going on? Where's the css? Just give me css!!" Поначалу все разработчики, с которыми я работаю, говорят: «Что, черт возьми, происходит? Где css? Просто дайте мне css!!» and then they're like "Ohhhh. riiight. Got it. Magic." а потом они такие: «Оооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооооо».

In the longer term I think the current approach is going to become ever more powerful as the world moves to low/no code solutions (eg like sketch or figma, but outputting an actual routed app and set of components rather than a set of wireframes) - having styles expressed as an object unlocks the ability to introspect that - and create more new features in such an environment (like provision of a schema enabling direct use of MUI components within a CMS, or generation of 'theme from this' and hundreds I haven't thought of yet). В долгосрочной перспективе я думаю, что текущий подход станет еще более мощным, поскольку мир переходит к решениям с низким/отсутствием кода (например, как скетч или фигма, но с выводом фактического маршрутизируемого приложения и набора компонентов, а не набора каркасов). - наличие стилей, выраженных в виде объекта, открывает возможность самоанализа - и создания новых функций в такой среде (например, предоставление схемы, позволяющей напрямую использовать компоненты MUI в CMS, или создание «темы из этого» и сотни I пока не придумал).

Moving back to the more raw-css kind of approach of styled-components doesn't preclude that - but it does make a lot of things (particularly parameterisation on the theme) a lot jankier and frustrating to achieve, and still requires much more in-depth knowledge of CSS's technicalities making it less accessible to new programmers and creative types alike. Возвращение к более сырому CSS-подходу styled-components не исключает этого, но делает многие вещи (в частности, параметризацию темы) намного более дергаными и разочаровывающими для достижения, и все еще требует гораздо более глубокое знание технических особенностей CSS делает его менее доступным как для новых программистов, так и для творческих личностей.

On the evolution of the state-of-the-art, I think styled-components has become really popular because it's a great step in the right direction from where the world was (which is why it became popular). Что касается эволюции современного искусства, я думаю, что styled-components стал действительно популярным, потому что это большой шаг в правильном направлении от того, где был мир (именно поэтому он стал популярным). But the existing MUI styles system is the next step on from that; Но существующая система стилей MUI является следующим шагом вперед; not an incorrect side-step. не неправильный шаг в сторону. Once everyone's migrated to styled-components then the question will be "wait: why on earth are we doing this with these weird raw strings in our components...?" Как только все перейдут на styled-components, возникнет вопрос: «Подождите: с какой стати мы делаем это с этими странными необработанными строками в наших компонентах…?»

Maybe I'm totally wrong, but for my $0.02, I'm begging you to stay the course for at least another major version :) Может быть, я совершенно не прав, но за мои 0,02 доллара я умоляю вас придерживаться курса хотя бы на другую мажорную версию :)

@thclark your main concern seems to be with the CSS template string syntax vs the JavaScript style object API. @thclark вас больше всего беспокоит синтаксис строки шаблона CSS по сравнению с API объекта стиля JavaScript. Is this accurate? Это точно? It also seems to be the concern with most of the other comments of the thread. Это также, кажется, беспокоит большинство других комментариев в ветке.

Styled-components and emotions support both APIs. Стилизованные компоненты и эмоции поддерживают оба API. This wasn't the main purpose of the issue. Это не было основной целью выпуска. The objective of this issue was to anticipate the migration to a different styling solution. Цель этого выпуска состояла в том, чтобы предвидеть переход на другое решение для стиля. However, we never move forward with "use styled-components in all the demos even if we didn't migrate the core engine". Однако мы никогда не продвигаемся вперед с «использованием стилизованных компонентов во всех демонстрациях, даже если мы не перенесли основной движок». We have opted for keeping both synchronized. Мы выбрали синхронизацию обоих.
At this point, keeping the issue open doesn't add much value outside triggering discussions like this one :). На данный момент сохранение проблемы открытой не имеет большой ценности, кроме как инициирование дискуссий, подобных этой :). We have to migrate the demos anyway for #22342. Мы все равно должны перенести демоверсии для #22342.

I personally prefer the JavaScript API over the CSS string one because: Лично я предпочитаю API JavaScript, а не строковый CSS, потому что:

• It doesn't ask for another linter/formater. Он не запрашивает другой линтер/форматер.
• I'm used to it. Я привык к этому.
• It plays nicely with TypeScript. Он прекрасно работает с TypeScript.

However, it's unclear what the community, at large, will enjoy using most. Однако неясно, что больше всего понравится сообществу в целом. CSS template has its advantages too. Шаблон CSS тоже имеет свои преимущества. It's easier to copy & paste code between the browser and the code. Легче скопировать и вставить код между браузером и кодом. A lot more people (overall: designers, developers, etc.) are familiar with the approach. Гораздо больше людей (в целом: дизайнеров, разработчиков и т. д.) знакомы с этим подходом.

To be noted that I think that we should use the style utilities as much as possible in the demos with v5. Следует отметить, что я думаю, что мы должны как можно больше использовать утилиты стилей в демонстрациях с v5.

@mnajdova any thoughts on the matter? @mnajdova есть мысли по этому поводу? Maybe it's worth asking the community on a poll. Может быть, стоит задать вопрос сообществу в опросе.

@oliviertassinari succinctly put, as usual. @oliviertassinari , как обычно, лаконично. Yes, my main concern is retaining the Javascript API. Да, моя главная забота — сохранить Javascript API. Honestly, I wasn't aware that styled-components retained that, as all of the examples I came across seem to be css templated. Честно говоря, я не знал, что styled-components сохранили это, так как все примеры, с которыми я сталкивался, кажутся шаблонами css.

That perhaps moots most of my points above. Это, возможно, спорит с большинством моих пунктов выше. Nevertheless, glad you didn't move across - and thanks for your and the team's continued efforts here. Тем не менее, рад, что вы не переехали, и спасибо за ваши постоянные усилия и усилия команды. I've built things I never could have without MUI existing. Я создал вещи, которые никогда не смог бы получить без MUI.

This issue is being resolved in v5. Эта проблема решается в v5. We have migrated the documentation of the slider to the new approach: https://next.material-ui.com/components/slider-styled/. Мы перенесли документацию слайдера на новый подход: https://next.material-ui.com/components/slider-styled/. We use the sx prop anytime simple CSS are necessary then use the styled API for more heavy customizations. Мы используем реквизит sx всякий раз, когда необходим простой CSS, а затем используем API styled для более сложных настроек. I believe the previous concern raised have been handled, if not, please comment :). Я считаю, что предыдущая проблема была решена, если нет, пожалуйста, прокомментируйте :).