Open omerman opened 2 years ago
@omerman Thank you for your interest in solving this issue (#192)!
I don't want to merge this however because of some limitations it has:
MyContextProviderComponent
(e.g. MyContext.Provider value
, or HistoryRouter router
). This is severely limiting. Also, not exactly a limitation but an ergonomic thing: you would have to explicitly specify which context(s) you want to provide, when I think we can assume users just want whatever contexts are provided to the component from which the alert is fired.
I believe a more complete solution is possible, even one that covers # 3 and the ergonomic issue. I believe the more complete solution would involve using portals to render the given react element(s) within the component from which the alert is fired. Portals are needed to do this since the alert is rendered (without React) outside your React app's DOM tree
At first glance I tried seeking a solution that will use the App context, such as portals, but there wasn't a quick one to write. The solution I propose simply gets rid of the boilerplate of rendering a context for each usage. I will take another crack at it, I think I have a more elegant idea on how to impl this with a poral. I'll keep you posted 😊
@zenflow I've added support for Portal. The code itself is not ideal, but it works as expected. It should also solves some of the issues you mentioned.
App = () =>
<Router ...>
<ThemeProvider ..>
{...}
<SwalRoot />
</ThemeProvider>
<Router />
ReactSwal.fire(...) // would have the desired contexts because it uses React's Portal api.
@ zenflow 😢 ?
@zenflow In the meantime I'm using my fork, but I really think you should consider approving this pr.
I changed it to use Portals
as we discussed.
It works well, Im using it for including my Mui Theme provider for example..
Please let me know what you think
@limonte
Hi @omerman sorry for the long delay. I'll have a look at this on Sunday. Just two notes for now:
@zenflow I think that 99% of the usecase will not need to set up different Swal behaviors, meaning it will probably be placed under the app providers and be expected to work under those contexts.
I did fiddle around with the concept of placing a Swal provider under different tree levels of react dom, exposing hooks and holding a token that will be used when Launching a popup, but I decided it's a small edge case.
Having said that, If we decide to support this case, I believe it can be done without breaking the current behavior. It could have the same api and if not supplied with a Swal hook's key while launcing a pop up, we will take the closest to Root node Swal context.
Hope you understood my explanation 😅
And regarding your tests, If you want I'll add you as a collaborator on my fork and you can add the files, or send it here as a comment and I'll run it