Material-ui: 在所有演示中使用 styled-components

@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.我们尽可能用 Box 组件替换演示中 @material-ui/styles 的使用。 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.如果我们需要扩展/规范化样式组件的一些特性，它会有所帮助。

@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.但是，它可能需要进行重大更改，v5 计划在 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 ).我想你今天已经在 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).我想你今天已经在 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很满意，并且在使用 Material UI 时我没有使用styled-components （我会删除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（今天）时不使用 styled-components？ We had 1/3 of our users going down this path when we did our last survey, 6 months ago.当我们在 6 个月前进行上一次调查时，我们有 1/3 的用户走上了这条路。

I don't fully understand this point.我不完全理解这一点。 Why not using styled-components when using Material-UI (today)?为什么在使用 Material-UI（今天）时不使用 styled-components？

@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.我尝试在styled-components中使用props.theme $ 但没有用，我不确定您是否有建议，但我认为我们需要添加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:您发布的链接应该显示出对样式组件越来越感兴趣，最近开始显示出下降趋势：

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 .建议在2019 年 5 月更新中对此进行查看。

So far it only recovered to pre-v5-hype.到目前为止，它只恢复到 v5 之前的炒作。 Let's see how the updated data point for January till now looks.让我们看看 1 月到现在的更新数据点的样子。

@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 组件的实用性 - 可以在 prop 值中使用主题变量等，但是 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 ?"像这样的缩写似乎没有必要，使事情变得模棱两可，并向开发人员介绍了一个新的学习曲线，将缩写映射到他们现在需要记住的实际属性：“使用 $#$4$ 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.其次，组件抽象出最常见的反复出现的 UI 模式，并创建 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 $16$#$ 之类的道具 - 而不是接受几乎任何填充或边距。 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?举个例子，为什么在 Typography 下使用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?如果我们在底层使用 Box 构建 ListItem ，我们是否需要引入BoxProps={{ padding: 2 }} ，或者还接受dense道具，基于它我们编写逻辑以将padding道具应用于特定的盒子，还是别的什么？

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).保持相同的classes API（第一次出现在 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.与当前默认的 Material Desing Theme 相比，它不那么固执己见，但使用了相同的主题规范。
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.在某些时候，我们考虑过在@doctolib的设计系统中隐藏所有 className 属性。 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.我只是认为如果您在 js 解决方案中有两个 css 会增加很多臃肿。

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).从长远来看，我认为随着世界转向低代码/无代码解决方案（例如草图或 figma，但输出实际路由应用程序和一组组件而不是一组线框），当前的方法将变得更加强大- 将样式表示为对象解锁了自省的能力 - 并在这样的环境中创建更多新功能（例如提供能够在 CMS 中直接使用 MUI 组件的模式，或生成“来自此的主题”和数百个 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).关于 state-of-the-art 的演变，我认为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...?"一旦每个人都迁移到样式组件，那么问题将是“等等：我们到底为什么要在我们的组件中使用这些奇怪的原始字符串......？”

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 模板字符串语法与 JavaScript 样式对象 API。 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:我个人更喜欢 JavaScript API 而不是 CSS 字符串之一，因为：

• It doesn't ask for another linter/formater.它不要求另一个 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.只要需要简单的 CSS，我们就使用sx属性，然后使用styled API 进行更重的自定义。 I believe the previous concern raised have been handled, if not, please comment :).我相信之前提出的问题已经得到解决，如果没有，请发表评论:)。