{"action":"created","issue":{"url":"https://api.github.com/repos/react-navigation/rfcs/issues/24","repository_url":"https://api.github.com/repos/react-navigation/rfcs","labels_url":"https://api.github.com/repos/react-navigation/rfcs/issues/24/labels{/name}","comments_url":"https://api.github.com/repos/react-navigation/rfcs/issues/24/comments","events_url":"https://api.github.com/repos/react-navigation/rfcs/issues/24/events","html_url":"https://github.com/react-navigation/rfcs/issues/24","id":297381589,"number":24,"title":"Configuring screen options based on props and state","user":{"login":"satya164","id":1174278,"avatar_url":"https://avatars2.githubusercontent.com/u/1174278?v=4","gravatar_id":"","url":"https://api.github.com/users/satya164","html_url":"https://github.com/satya164","followers_url":"https://api.github.com/users/satya164/followers","following_url":"https://api.github.com/users/satya164/following{/other_user}","gists_url":"https://api.github.com/users/satya164/gists{/gist_id}","starred_url":"https://api.github.com/users/satya164/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/satya164/subscriptions","organizations_url":"https://api.github.com/users/satya164/orgs","repos_url":"https://api.github.com/users/satya164/repos","events_url":"https://api.github.com/users/satya164/events{/privacy}","received_events_url":"https://api.github.com/users/satya164/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":11,"created_at":"2018-02-15T09:42:46Z","updated_at":"2018-02-20T08:42:27Z","closed_at":null,"author_association":"NONE","body":"Currently the screen options can be specified statically. If you need to configure any options based on props and state of the component, or want to update state and props based on some action such as tab press, you need to do it in a hacky way by changing params. it's way more complicated than it needs to be. It also breaks when used with HOCs which don't hoist static props, a common source of confusion. ([#145](https://github.com/react-navigation/react-navigation/issues/145), [#2725](https://github.com/react-navigation/react-navigation/issues/2725), [#2804](https://github.com/react-navigation/react-navigation/issues/2804), [#2955](https://github.com/react-navigation/react-navigation/issues/2955))\r\n\r\n### Proposal\r\n\r\nWe can add an additional method `setOptions` on the `navigation` prop:\r\n\r\n```js\r\nclass Home extends Component {\r\n  constructor(props) {\r\n    super(props);\r\n\r\n    this.props.navigation.setOptions({\r\n      title: 'Home'\r\n    });\r\n  }\r\n\r\n  render() {\r\n    ...\r\n  }\r\n}\r\n```\r\n\r\nIf you call `setOptions` again at some point, the object is shallow merged with previous configuration. It might seem a little ugly at first, but this imperative API allows us to build a declarative API on top of it:\r\n\r\n```js\r\nfunction Profile({ route }) {\r\n  return (\r\n    <React.Fragment>\r\n      <NavigationOptions\r\n        title={`${route.user}'s Profile`}\r\n      />\r\n      <ScreenContent />\r\n    </React.Fragment>\r\n  );\r\n}\r\n```\r\n\r\n`NavigationOptions` is a React component that can be used to configure the current screen from the render method. It's very useful when your screen's configuration depends on the props, state or both. ([#2546](https://github.com/react-navigation/react-navigation/issues/2546))\r\n\r\nThe static way of specifying the config can still be supported for simplicity and backward compatibility."},"comment":{"url":"https://api.github.com/repos/react-navigation/rfcs/issues/comments/366905679","html_url":"https://github.com/react-navigation/rfcs/issues/24#issuecomment-366905679","issue_url":"https://api.github.com/repos/react-navigation/rfcs/issues/24","id":366905679,"user":{"login":"grabbou","id":2464966,"avatar_url":"https://avatars2.githubusercontent.com/u/2464966?v=4","gravatar_id":"","url":"https://api.github.com/users/grabbou","html_url":"https://github.com/grabbou","followers_url":"https://api.github.com/users/grabbou/followers","following_url":"https://api.github.com/users/grabbou/following{/other_user}","gists_url":"https://api.github.com/users/grabbou/gists{/gist_id}","starred_url":"https://api.github.com/users/grabbou/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/grabbou/subscriptions","organizations_url":"https://api.github.com/users/grabbou/orgs","repos_url":"https://api.github.com/users/grabbou/repos","events_url":"https://api.github.com/users/grabbou/events{/privacy}","received_events_url":"https://api.github.com/users/grabbou/received_events","type":"User","site_admin":false},"created_at":"2018-02-20T08:42:27Z","updated_at":"2018-02-20T08:42:27Z","author_association":"NONE","body":"I second the API presented in [previous comment](https://github.com/react-navigation/rfcs/issues/24#issuecomment-366370481). I've been partially prototyping this out in my free time recently, thanks to @ericvicenti pointing me towards that direction.\r\n\r\nWe had this idea of making it easy to just render a `header` component instead of `title`, `right` and other navigation options:\r\n```js\r\nclass HomeScreen extends React.Component({\r\n  render() {\r\n    return (\r\n      <Screen header={<Header title=\"Welcome\" />}>\r\n        {...screenContent}\r\n      </Screen>\r\n    );\r\n  }\r\n});\r\n```\r\n\r\nThis allows for easy customization of the header. If the header is not set on Screen, it will not be rendered at all. It also makes it easy for people to connect their state with the header which I guess has been one of the most common requests.\r\n\r\n> It's an interesting idea, but keep in mind that sometimes Header is shared between routes instead of being present inside the Route's card. This is the case on iOS and possibly the case if you are trying to implement Material Design style shared element transitions on Android like you see in Google's apps (try Inbox for example).\r\n\r\nAs @satya164 mentioned, this can be done with a similar to React's portal pattern - effectively, reusing the existing implementation of the header. However, I've been thinking to what degree we could achieve native-like look&feel of the header by having it separate on each screen and figuring out a new way for shared-element transitions.\r\n \r\n\r\n\r\n"}}
{"actor":{"display_login":"grabbou"}}