Refactor as an input for using isOpened correctly about react-portal HOT 3 CLOSED

I think I don't get it. What's the use case? Pull request?

from react-portal.

Don't have a PR yet.

The use case is related to maybe

<A>
  <Portal isOpened={some A state}/>
</A>

and you forget onClose to change the state in A responsible for isOpened back to false. If something triggers a rerender of A, your Portal will open back up and you will be left scratching your head.

In controlled state, if you omit the onChange equivalent you have a warning that if you are using isOpened, you need to use to listen to closing events, and then it's a simple matter of opening/closing the portal related to isOpened in componentWillReceiveProps and simply trigger the listener in closeOnEscape, closeOnClickOutside, etc ...

But by default, the portal will not close up anymore if you use isOpened, user have to send isOpened to false for closing/opening logic to happen only in componentWillReceiveProps (and componentWillUnmount) via isOpened. closeOnEsc, closeOnOutsideClick and calling closePortal from the portal children, will simply trigger the onChange (or whatever you want to call it) so that user can do his stuff for the state (isOpened in this case).

Just like a controlled input.

from react-portal.

I get it know. This is a good idea. Yeah, it would be helpful to introduce the onChange prop for the controlled state. It doesn't have to be mandatory (or firing some warning) though - no unnecessary BC break. People still can use the controlled state if they already implemented all closing logic in upper layers (outside of react-portal). Also, if they don't need to utilize closeOnEsc, closeOnOutsideClick or closePortal, onChange would be redundant (use-case when the portal is opened and closed programmatically, by server... etc).

Also, the README.md should be updated with terms controlled / uncontrolled. It really makes sense and it is a concept that React devs are familiar with already (from forms).

from react-portal.