[IconMenu] Add open, onRequestOpen, onRequestClose properties, fix #2341

[quangbuule]

No description provided.

[alitaheri]

Nice work 👍
However, the convention around this library for declarative api is to use onRequestChange with requested open state change as argument. Also, since there can be more reasons why open=false is requested the better api would be: onRequestChange(open, reason). where reason can be: 'itemClick', 'clickaway' or else. This makes the usage a lot easier as people can just do:

onRequestChange={(open, reason) => { if (reason === 'clickaway') this.setState({open}); }}

[oliviertassinari]

Shouldn't this update the open state depending the prop.open in the getInitialState method?

[quangbuule]

I forgot about this.

[oliviertassinari]

Yeah, nice work. Could you take into account @subjectix feedback?

[quangbuule]

Btw, onRequestClose and onRequestOpen followed Dialog convention. Should we do onRequestChange on this PR?

[oliviertassinari]

Well, that's a good question!
To sum up we have:

• for the Dialog: onRequestClose(buttonClicked)
• for the Popover: onRequestClose(reason)
• for the LeftNav: onRequestChange(open, reason)
• for this component I would say onRequestChange(open, reason) because we can either resquest a close or an open event.

Sure, we could improve the consitency. Though? @shaurya947 @subjectix @chrismcv

[quangbuule]

It's okie with onRequestChange. But there is something I concern about naming.

1. If onRequestChange means when "request" change, So what is request, and it seems we are having current request value, and it's changing, in my head, request in this case is an event, not a value. So the onRequestChange make me confused a little bit.
2. If onRequestChange is just simple the Component is willing to change something, then it should wrap onChange, it's confusing anyway.

That's my concern, but I am okie with our convention :).

[oliviertassinari]

I would say that it's better to use onRequestChange(open, reason) here.

[quangbuule]

Okie. Another question: what is the reason when user select menuItem by Enter key? menuItem or keyboard?

[alitaheri]

onChange somehow means: This component was change, you may do something about it if you wish not the factual This component was demanded to change it's state. If you wish, you can change the prop value you provided to react to the change. However, I can't argue that onRequestChange is indeed confusing by itself. @quangbuule you sure challenge the conventions good :D :D
For this PR keep all the conventions intact. we have to make some changes all over the place to address this.

@quangbuule Do the honor and open 2 issues regarding both onRequestChange and default: undefined. Your arguments are valid, but we need the community's feedback on this.

[quangbuule]

@subjectix So what do you think about this:

<input value={this.state.text} onChange={{} => {/* I accepted the factual by doing nothing here */} />

Will the input value be changed after onChange?
Sorry about arguing too much on this :P

[oliviertassinari]

Well, it depend on how you intreprete the different properties of https://facebook.github.io/react/docs/two-way-binding-helpers.html

[quangbuule]

It's okie for me with onRequestChange and the null open in this PR. We will have issues on naming later. @subjectix @oliviertassinari, can you take a look at my above question?
#2343 (comment)

[alitaheri]

@quangbuule Well, I myself like onChange a lot more, it's a lot easier for me to write. But the community must decide. Open issues and lets discuss them with everyone. You have some great ideas 👍 👍
About your question. I think 'enter' would do. Thoughts @oliviertassinari ?

[oliviertassinari]

what is the reason when user select menuItem by Enter key? menuItem or keyboard?

Why not just calling it enter?