[Stepper] Reuse from component library causes StepperContext props to not work properly
@mnajdova is already working on this.
Since Oct 11, 2022.
- Dominant language
- JavaScript
- Stars
- 99.1k
- Forks
- 32.5k
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 106
Description
Duplicates
- I have searched the existing issues
Latest version
- I have tested the latest version
Current behavior 😯
Reusing MUI Stepper from own component library causes it to misbehave. Properties that come form the StepperContext are not working properly and/or missing.
Expected behavior 🤔
Reusing MUI Stepper from own component library should not introduce Context related issues.
Steps to reproduce 🕹
Steps:
- Re-export a Stepper component from a library
- Use it in another application
- Use children directly from MUI (ex:
Stepcomponent)
Context 🔦
Not sure if this is a bug or an intended behavior. I tried to isolate it and came to the conclusion that something gets messed up with the Context Provider. We have a requirement to build a reusable react component library with the following stack: React, Typescript, MUI, Storybook. Some of the components are just going to be 1:1 with what exists in MUI, and so, to avoid importing components from multiple libraries, we decided to re-export every MUI component that we use. Our Stepper re-export looks something like this(we tried different variations, with no mapping as well, just returning plain <MUIStepper {...props} />):
export const Stepper = ({ children, ...rest }: StepperProps) => {
return (
<Stack sx={{ width: '100%' }} spacing={4}>
<MUIStepper {...rest}>
{React.Children.map(children, (child) =>
React.isValidElement(child)
? React.cloneElement(child)
: child
)}
</MUIStepper>
</Stack>
);
};
Since it would take a while to also do it for every descendent type of Stepper (StepButton, StepConnector etc.), and to probably write tests for them, we gave up on the idea of re-exporting everything and tried to use descendants directly from MUI, but this breaks the behavior of the root component.
We've also tested the issue with the Accordion component, which renders the same behavior, but works as intended when we re-export AccordionSummary and AccordionDetails and use them from our library
Is there a way to correctly approach this issue without the constraint of using components from a single library? (either our own or MUI)? Can the Context be somehow controlled here?
Your environment 🌎
npx @mui/envinfo
Browser used: Chrome 103.0.5060.53
System:
OS: macOS 12.4
Binaries:
Node: 16.14.2 - /usr/local/opt/node@16/bin/node
Yarn: Not Found
npm: 8.5.0 - /usr/local/opt/node@16/bin/npm
Browsers:
Chrome: 103.0.5060.53
Edge: Not Found
Firefox: Not Found
Safari: 15.5
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.