[docs] Improve codesandbox generation logic#22221
Conversation
eps1lon
left a comment
eps1lon
left a comment
There was a problem hiding this comment.
The existing logic considered peer dependencies which core seems to be. The lab has a peer on core and so should the grid.
While the new logic is a decent approximation I see no reason to approximate it if we already have existing accurate logic.
|
@eps1lon The motivation would be to edge for a known future, assuming we will have dozens of packages. Maintaining the list of peer dependencies could be overkill compared to the cost of overloading in codesandbox. It was already frustrating for |
b433cb0 to
b69bc9c
Compare
b69bc9c to
7631887
Compare
eps1lon
left a comment
eps1lon
left a comment
There was a problem hiding this comment.
The point is that if the logic for peer dependencies is lacking then it's lacking for every package not just core. This is the sort of code we'll forgot about if we change the package structure and in line with "no abstraction is better then the wrong one".
It seems to me the existing logic isn't re-used because it might look "unclean" or includes "just copying code". Both these things are fine since they better reveal the underlying logic.
3 participants
When using the export to codesandbox feature of the demos with the data grid, we get: https://codesandbox.io/s/quirky-galois-9kfv5?file=/demo.tsx. For instance, using https://deploy-preview-165--material-ui-x.netlify.app/components/autocomplete/#ComboBox.tsx. I think that we can simply include @material-ui/core, always in the list of dependency. It seems to be a simple default, with no significant downside.
Closes mui/mui-x#157