Ability to add an id to tabs item and pass it to its onPress handler

[julien-rodrigues]

Hi guys,

I'm currently using your lib but I'm not a big fan of how the onPress handler is currently working. I'm going to fork to make some changes about this as the project I'm working on would greatly benefit from these, and I thought you might be interested in some of these ideas.

First, to be clear, I like the idea of adding a maximum of flexibility by letting dev specify an handler on every tab item. But when you want to perform the same action every time you press on a tab, this is quite an unneeded overhead to me.

In this case having the possibility to pass the onPress handler to the top wrapper could be nice.

Example:

<TabNavigator onPress={() => alert('Pressed')}>
  <Item>...</Item>
  <Item>...</Item>
  ...

Of course, having this behaviour is useless if you can't change the selected scene, that's why on top of this change I would allow for a name or id property to be added on the TabNavigator.Item component. This way the onPress handler would be able to receive it as an argument and we could easily change the selected tab by using it.

Example:

<TabNavigator onPress={(event, tabId) => this.setState({activeTab: tabId})}>
  <Item id="tab1" selected={this.state.activeTab === 'tab1'}>...</Item>
  <Item id="tab2" selected={this.state.activeTab === 'tab2'}>...</Item>
  ...

To keep the granularity, we can make this so if the onPress handler is not on the Item then we fallback on the top level one. If no id or name property is placed on the Item then it would be undefined as the second argument. This would also ensure the api is backward compatible.

Please tell me your thoughts on this and I could make a PR on this repo, enabling us to not having to maintain a fork.

Thanks!!

[ide]

My suggestion is to write your own component that renders a TabNavigator and takes one onPress handler and applies it to all of the child Items. That way you can get the API you want without forking.

[julien-rodrigues]

Indeed that's what we did but we thought this could maybe be part of the component API.

Thanks!