[ExpansionPanel] Rename to Accordion

[mnajdova]

Breaking changes

• [ExpensionPanel] Rename the ExpansionPanel components with Accordion to match the naming convention of the community:

  -import ExpansionPanel from '@material-ui/core/ExpansionPanel';
  -import ExpansionPanelSummary from '@material-ui/core/ExpansionPanelSummary';
  -import ExpansionPanelDetails from '@material-ui/core/ExpansionPanelDetails';
  -import ExpansionPanelActions from '@material-ui/core/ExpansionPanelActions';
  +import Accordion from '@material-ui/core/Accordion';
  +import AccordionSummary from '@material-ui/core/AccordionSummary';
  +import AccordionDetails from '@material-ui/core/AccordionDetails';
  +import AccordionActions from '@material-ui/core/AccordionActions';  
  
  -<ExpansionPanel>
  +<Accordion>
  -  <ExpansionPanelSummary>  
  +  <AccordionSummary>
       <Typography>Location</Typography>
       <Typography>Select trip destination</Typography>
  -  </ExpansionPanelSummary>  
  +  </AccordionSummary>
  -  <ExpansionPanelDetails>
  +  <AccordionDetails>
       <Chip label="Barbados" onDelete={() => {}} />
       <Typography variant="caption">Select your destination of choice</Typography>
  -  </ExpansionPanelDetails>  
  +  </AccordionDetails>
     <Divider />
  -  <ExpansionPanelActions>  
  +  <AccordionActions>
       <Button size="small">Cancel</Button>
       <Button size="small" color="primary">Save</Button>
  -  </ExpansionPanelActions>   
  +  </AccordionActions>
  -</ExpansionPanel>
  +</Accordion>

---

This PR is inspired by @oliviertassinari comment #20580 (comment) for renaming the ExpansionPanel* components to Accordion*.

I think that we should rename the component in v5 ExpansionPanel -> Accordion. The pros:

Help users migrating from Bootstrap to Material-UI: https://getbootstrap.com/docs/4.4/components/collapse/#accordion-example.
Help users already familiar with a11y components: https://www.w3.org/TR/wai-aria-practices-1.1/examples/accordion/accordion.html.
Break free from MD, help with future themes
The query has, at least, x5 more SEO traffic.

TODOs

• add migration entry
• add codemods?

Questions

• What do we do with the translations?
• Should we start preparing codemods for v5 (material-ui-codemod/src/v5.0.0)

[mui-pr-bot]

@material-ui/core: parsed: +0.05% , gzip: +0.12%
@material-ui/lab: parsed: 0.00% 😍, gzip: +0.35%

Details of bundle changes

Generated by 🚫 dangerJS against f034f65

[mnajdova]

How should we fix the codemod tests for v4?

[eps1lon]

Ideally the codemod would support the old and new names. If that's not possible then we can always only handle the new names and release the codemod in a major.

[eps1lon]

Makes sense now that the material guidelines no longer describe this component.

Though we don't want to loose the legacy ExpansionPanel traffic. We should add the moved pages to docs/public/_redirects (301)

[oliviertassinari]

For the URL, I think that we should continue with the singular: https://material-ui.com/components/accordion/ as we do with the new components in the lab.

[mbrookes]

What's the deprecation strategy for ExpansionPanel? Reexport with a warning, then remove in v6?

[mbrookes]

@mnajdova

I probably misunderstood the comments

I didn't help matters by asking a leading question. Sorry!

@eps1lon

Rather we work exclusively on breaking changes and backport it as non-breaking change later onto master.

Am I understanding correctly?:

1. Rename ExpansionPanel to Accordion on the next branch as a breaking change. (What @mnajdova had done originally.)
2. Later, backport the rename to master, reexporting Accordion as ExpansionPanel with a deprecation warning. (Essentially what this PR now covers now, but without the docs changes?)

[eps1lon]

Am I understanding correctly?:

Yes! The idea is generally to avoid:

• wasted effort if a breaking change is later reverted
• make the PR more focused
  A breaking change can already spark a lot of discussion. It's definitely useful to include a deprecation strategy in the discussion but an outline should be enough in my opinion.
• free up mental capacity for the current change so that you don't have to worry about breaking changes. This hopefully makes for a "fresher look" at the problem by getting rid of all the legacy baggage.

There's a concern that we might forget to deprecations later (as with any change that is scheduled for later). My hope is that it's far less likely since we can later look at all the breaking changes (filter by label) and see if we have a deprecation in place.

[mnajdova]

@eps1lon so should we revert the changes which are refering to the deprecation of the ExpansionPanel components from this PR?

[eps1lon]

@eps1lon so should we revert the changes which are refering to the deprecation of the ExpansionPanel components from this PR?

At this point that's even more work. This is good to go. Just something to consider in the future.

Just to make sure: In its current state this PR isn't breaking (ignoring dev-only warnings). I can still apply this change to existing codebases and have no change in production?

[mnajdova]

Just to make sure: In its current state this PR isn't breaking (ignoring dev-only warnings). I can still apply this change to existing codebases and have no change in production?

Exactly. We still have the previous folder structure for preserving the imports and all components and their typings are re-exported by their old names.

If there is anything else that should be done that I am not aware of, let me know. If there isn't then this PR is non-breaking.

[eps1lon]

Some of the markdown files are not considered as moved in git e.g. docs/src/pages/components/accordion/accordion.md (while -aa is correctly marked as moved). This can become problematic when looking through the history.

Most of the time git automatically figures this out. For all the other cases you need to explicitly git mv. I guess you need revert these moves and then git mv instead of mv those files. This might be difficult to get right but may be invalueable later!

[mnajdova]

Some of the markdown files are not considered as moved in git e.g. docs/src/pages/components/accordion/accordion.md (while -aa is correctly marked as moved). This can become problematic when looking through the history.

Most of the time git automatically figures this out. For all the other cases you need to explicitly git mv. I guess you need revert these moves and then git mv instead of mv those files. This might be difficult to get right but may be invalueable later!

@eps1lon git mv works as expected (shows the file as renamed), see commit 13c6553 but then after I edit the file, the commit looks good: 957fef9 but the whole PR automatically again shows the old one as deleted, and the other file as new one. And then gitk shows me only the history after the renaming :\ But's it definitely strange why it works with some files, and not with others.. Is there some other way of how we can fix this?

Final note: Everything was done in separate commit, but still the end result is unexpected..

[eps1lon]

Tried but it failed ultimately. Didn't find confirmation that renaming is even a separate thing in git or if it derives this from commits. Probably too much effort for marginal gain long term. We don't trace markdown very often anyway.