Of course, these conflicts doesn't only happen with config, but also with wrapWith and all the rest of the Parcel props, but the config case is the worst because it causes the Parcel not to render at all.
It seems like a solution to this, without introducing a breaking change, would be to have a new prop named something like parcelProps... If that prop is used, the props object to pass to the microfrontend could be that one, instead of the ones at the first level. It would be optional and if nothing is passed, it could continue working as before.
Does this make sense? I think it should be a simple enough change, I could attempt to do it myself :)
(Seems like the change is mostly on propTypes and here, and then of course the docs could need a change)
Hi, thank you for submitting the proposal. To me, proposal looks valid. Codemod could also be provided to migrate users to the new approach. @joeldenning, @robmosca what do you think?
The way the API is thought, it expects microfrontend props to be passed at the same level than the rest of the props..
This causes this code to fail if the microfrontend props contain a prop named "config"
Of course, these conflicts doesn't only happen with
config
, but also withwrapWith
and all the rest of the Parcel props, but theconfig
case is the worst because it causes the Parcel not to render at all.It seems like a solution to this, without introducing a breaking change, would be to have a new prop named something like
parcelProps
... If that prop is used, the props object to pass to the microfrontend could be that one, instead of the ones at the first level. It would be optional and if nothing is passed, it could continue working as before.Does this make sense? I think it should be a simple enough change, I could attempt to do it myself :) (Seems like the change is mostly on propTypes and here, and then of course the docs could need a change)