[docs] Remove use of StyledEngineProvider at the top of the App

[mnajdova]

Updates done in the PR:

• removes the use of <StyledEngineProvider injectFirst> at the top of the app
• uses custom cache provider only if rtl is on
• uses enhanceApp in favor of enhanceComponent

Tested:

• rtl is working
• dark mode is working
• global styles are not leaking

Preview: https://deploy-preview-27358--material-ui.netlify.app/

[mui-pr-bot]

No bundle size changes (experimental)

Generated by 🚫 dangerJS against 7550794

[mnajdova]

We need to first not have any makeStyles usages on the docs in order for this to work.

[oliviertassinari]

Does it mean we can close #16947? cc @vicasas Are we done? I'm not sure

[vicasas]

Are we done?

@oliviertassinari From what I remember, some module files are missing from the onepirate template. And all the others that don't have a check.

[mnajdova]

Does it mean we can close #16947? cc @vicasas Are we done? I'm not sure

There are few occurrences, I will remove them as part of this PR

[oliviertassinari]

There are few occurrences, I will remove them as part of this PR

@mnajdova I had a quick look. I could find the following components that are using JSS and that override emotion:

• Pro
• Quotes
• Sponsors
• Steps
• Users
• TopLayoutCompany
• TopLayoutBlog
• Ad
• ReactVirtualizedTable
• Team
• Onepirate/Snackbar
• Onepirate/TextField
• Onepirate/Typography

Regarding the broken search bar and drawer, it looks like this PR is not based on HEAD, so likely why we have issues.

[oliviertassinari]

@mnajdova Do you plan to resume the work on this PR or will it be delayed to post v5? If it's later, I propose we close. We can use the GitHub issues to keep track of the work that is left to be done #16947.

---

As a general note (not directly related to this PR, but it could be). We don't really have to use PRs as a personal bookmark, it could be done like on Google Keep, Evernote, etc. Would it make sense to enforce an automatic PR close logic for PRs inactive after, say 30 days, more? Maybe it would set a healthy constraint to stay in sync with what we wish our bandwidth would be, what its in reality, and what our true priorities are?
It would close all PRs that we have deprioritized (inactive for a while), it would lead to having the open PRs for ongoing work. My assumption is that it could 1. make it reviewing work more appealing (why? to know where to focus). 2. communicate to others what's up for grab (why? seeing something open doesn't open somebody else to work on the same problem).
When I look at vscode with 254 open PRs, Flutter with 168 open PRs, TypeScript with 273, I can't help myself thinking. How much of them are really relevant?

[mnajdova]

@mnajdova Do you plan to resume the work on this PR or will it be delayed to post v5? If it's later, I propose we close. We can use the GitHub issues to keep track of the work that is left to be done #16947.

We can close, I planned to work on it last week, but other things came up. I will re-open once I get back to this, or start from scratch...

As a general note (not directly related to this PR, but it could be). We don't really have to use PRs as a personal bookmark, it could be done like on Google Keep, Evernote, etc. Would it make sense to enforce an automatic PR close logic for PRs inactive after, say 30 days, more? Maybe it would set a healthy constraint to stay in sync with what we wish our bandwidth would be, what its in reality, and what our true priorities are?

Agree, it makes sense. If someone haven't work on a PR for a month, it's likely that we can close.

[oliviertassinari]

A fun one in the OSS landscape https://github.com/odoo/odoo, more PRs open than issues 😁

I have open #16947

If someone haven't work on a PR for a month, it's likely that we can close.

To see if this is the right threshold, could be higher, like 3 months. But I think that there is a notion of: I don't spend time on X === it's not important enough or it's blocked by something else => close.