Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature request] A boolean prop indicating to not use React Native's Modal #120

Open
SimpleCreations opened this issue Sep 1, 2021 · 3 comments · May be fixed by #145
Open

[Feature request] A boolean prop indicating to not use React Native's Modal #120

SimpleCreations opened this issue Sep 1, 2021 · 3 comments · May be fixed by #145
Labels
question Further information is requested

Comments

@SimpleCreations
Copy link
Contributor

SimpleCreations commented Sep 1, 2021

Ask your Question

I have a case where I need to display two dialogs on top of each other (#116), and as a workaround I use React Navigation to manage the stack. But due to the way React Native's <Modal> works, the second dialog still doesn't render in this case. To finally fix this issue I've patched the source removing <Modal> (and replacing it with React.Fragment).

Would be nice to have an option to do this using the library's API, similarly to how react-native-modal has the coverScreen prop.

@SimpleCreations SimpleCreations added the question Further information is requested label Sep 1, 2021
@mmazzarolo
Copy link
Owner

Hi @SimpleCreations , thanks for creating the thread :)
I understand the issue, and I agree that the native modal behavior is not always convenient here.

I'm not a fan of the coverScreen approach though unless we also provide a way to show the modal at the root node.
My plan here is to:

  1. Extract the current modal implementation into a smaller package (I've already one it) so that it can be shared between this project and react-native-modal-datetime-picker and be used by other apps.
  2. Update the new small modal package so that it can support both the current built-in modal flow and a way to be portal-ed into the root.
  3. Allow picking the preferred solution in the modal package consumers.

Related ongoing discussions:

In the short term, I'm ok with adding the coverScreen behavior, but only with a yellow warning mentioning that it's experimental and will be deprecated (as I'm not planning to maintain it).

@SimpleCreations
Copy link
Contributor Author

My plan here is to:

This sounds great 👍 However, I still think a coverScreen prop is very useful and maybe it's worth considering adding it without any warnings.

I personally grew fond of the approach of managing multiple dialogs with react-navigation.
This not only solves the issue with multiple React Native's Modals but also serves as a workaround for this issue in react-native-screens — basically if some screen has a modal presentation mode, there is no way to paint over it other than by using another modal screen (or with the recent commits using WindowView).
As a result, I believe with the new approach in react-native-dialog it most likely still will not be possible the paint over existing react-native-screens modals.

Perhaps there could be other reasons to manually manage the way the dialogs cover the screen, so I think there should be a way to opt out of default behavior with a prop.

@mmazzarolo
Copy link
Owner

basically if some screen has a modal presentation mode, there is no way to paint over it other than by using another modal screen (or with the recent commits using WindowView)

Yeah, since my initial reply I had a couple of chats and it will probably take a long time until we're able to truly portal a JS view on top of any screen (react-native-screens included).
Also, the WindowView approach is iOS only (we were waiting for it ).

So... in the meanwhile, I'm ok with coverScreen, if you wanna send a PR for it 👍

saghul added a commit to jitsi/react-native-dialog that referenced this issue Jun 20, 2022
@saghul saghul linked a pull request Jun 20, 2022 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants