rename isOpened prop to isOpen, add deprecation notice

[dlindenkreuz]

fixes #61

[tajo]

The deprecation notice should be produced by the library. isOpened should be still supported (aliased to isOpen) in the next major version v3. The complete removal can be done in v4.

[dlindenkreuz]

Adding a HOC to transform the props breaks almost all tests. Do you have a suggestion for providing isOpen that isn't super arduous? Just pushed a PropType validation with deprecation notice, though.

[ianstormtaylor]

+1 would love to see this merged!

[adamdicarlo]

"In the future" might be misleading here - this is an error, you have to use isOpen for the portal to work, right?

[tajo]

Yep. I'm going to change the message.

[tajo]

Merged. Thanks!

[STRML]

As a point of discussion (I can open up another issue if you like), why does this prop even exist?

It makes more sense to me to simply always render the portal if it's in the tree, and to just not render it if you want to hide it. Like so:

return (
  <div>
    <button onClick={() => this.setState({opened: !this.state.opened})}>Toggle</button>
    {this.state.opened ? 
      <Portal><div>Portal Contents</div></Portal>
    : null}
  </div>
);

[tajo]

I like the idea of not using isOpen. Can you open an issue / PR? I feel this deserves more discussion and attention from other people.

Why does this prop even exist?

I guess I thought it's more intuitive.