[Badge] Remove unused code

[eps1lon]

Reverts the parts of #24253 that affected the Badge. We cannot allow code in the codebase which we don't understand. If we do understand it, we should do everything we can to explain it. Code that is not understood or its purpose is kept a secret has no place in open source.

[mui-pr-bot]

Details of bundle changes

Generated by 🚫 dangerJS against 9886c01

[oliviertassinari]

If we do understand it, we should do everything we can to explain it.

The source on HEAD for the Badge component is following the latest template for writing components with the styled API. All the components are meant to follow the same template. I think that as long as the why is documented for one component following the template, it covers all the others. We have documented the why with the Button #24262 and #24253.

[mnajdova]

All style related functions (the styles, overrides resolver and the creation of the utility classes should use the styleProps as source of truth for the props). The implementation previously was wrong. What do you mean we don’t understand, or how come we understand the previous implementation and not this one?

[eps1lon]

What do you mean we don’t understand, or how come we understand the previous implementation and not this one?

If you are not able to explain what code does, you do not understand it.

how come we understand the previous implementation and not this one?

I did not make this claim. I'm actually saying that we don't understand either one.

All style related functions (the styles, overrides resolver and the creation of the utility classes should use the styleProps as source of truth for the props).

Where is this documented? We should create an API that either catches mistakes or makes them impossible. Not create an API that is only understood by its creator.

All the components are meant to follow the same template.

Where is this documented?

We have documented the why with the Button #24262 and #24253.

Where did you document it? That PR is too big to scan quickly and inssufficient as developer documentation.

[eps1lon]

Also could you explain to me when we're allowed to use templates and when we need to create abstractions? So far it seems to me that this just depends on the person making the change not what we're actually doing.

[mnajdova]

All style related functions (the styles, overrides resolver and the creation of the utility classes should use the styleProps as source of truth for the props).

Where is this documented? We should create an API that either catches mistakes or makes them impossible. Not create an API that is only understood by its creator.

My first thought was that we can pass only stylesProps on the overridesResolver and then we should be good to go, but it may be confusing when people use this for their own custom components and they don't have the convention of adding all styling props under one prop as we do. Let me know if you think otherwise on this one.

@eps1lon we still haven't created a universal RFC documentation to follow, as we are still dog fooding the implementation. This week I plan to create the RFC and track all converted components to emotion. Would that RFC be a good place for documentation things like this, or did you have something else in mind?

[mnajdova]

Can we close this one now that we have #24405 and the migration guide https://gist.github.com/mnajdova/b0562785b7cf1b9d9aeae382d578594b or should we extend the guide somehow?