add withNavigationFocus HOC

[slorber]

As discussed in other issues, we should be able to know easily which screen has the focus.

This HOC idea has been mentioned here by @satya164 and @ericvicenti

• screenIsActive prop / componentDidFocus event for TabNavigator items #51 (comment)
• screenIsActive prop / componentDidFocus event for TabNavigator items #51 (comment)
• Navigation Event Subscriptions #3345 (comment)

Here is a basic implementation using the new lifecycle hooks to provide this feature

[codecov-io]

Codecov Report

Merging #3512 into master will decrease coverage by 0.54%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master    #3512      +/-   ##
==========================================
- Coverage    72.6%   72.05%   -0.55%     
==========================================
  Files          51       52       +1     
  Lines        1595     1607      +12     
==========================================
  Hits         1158     1158              
- Misses        437      449      +12

Impacted Files	Coverage Δ
src/views/withNavigationFocus.js	0% <0%> (ø)
src/react-navigation.web.js	0% <0%> (ø)	⬆️
src/react-navigation.js	0% <0%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 69bca19...674389a. Read the comment docs.

[slorber]

just added an example to playground app: TabsWithNavigationFocus

[ericvicenti]

Yes, this is exactly what I had in mind. Thanks for the contribution!!

[slorber]

I updated the PR to get navigation from both props and context

[ericvicenti]

Oh yay, flow errors! 😭

Error: js/TabsWithNavigationFocus.js:7
  7: import { TabNavigator, withNavigationFocus } from 'react-navigation';
                            ^^^^^^^^^^^^^^^^^^^ Named import from module `react-navigation`. This module has no named export called `withNavigationFocus`.

Error: js/TabsWithNavigationFocus.js:21
 21:       <SampleText>Tab {name}</SampleText>
           ^^^^^^^^^^^^ React children array. Could not decide which case to select
 12: const SampleText = ({ children }: { children?: ChildrenArray<*> }) => (
                                                    ^^^^^^^^^^^^^^^^ union type. See: js/SampleText.js:12
  Case 1 may work:
  223:   declare export type ChildrenArray<+T> = $ReadOnlyArray<ChildrenArray<T>> | T;
                                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ read-only array type. See lib: /tmp/flow/flowlib_28386f1e/react.js:223
  But if it doesn't, case 2 looks promising too:
   12: const SampleText = ({ children }: { children?: ChildrenArray<*> }) => (
                                                                    ^ existential. See: js/SampleText.js:12
  Please provide additional annotation(s) to determine whether case 1 works (or consider merging it with case 2):
   21:       <SampleText>Tab {name}</SampleText>
                              ^^^^ name


Found 2 errors
error Command failed with exit code 2.
Exited with code 1

Looks like you need to add a definition for this new HOC in flow/react-navigation.js

[ericvicenti]

As for the getWrappedInstance vs props.onRef question, lets move that to a follow-up issue/PR/RFC, because we're already invested in props.onRef for now because of withNavigation. I don't have a strong preference either way, so I'll leave it up to y'all, but I believe that onRef requires a tiny bit less boilerplate for people.

RFC

[slorber]

fixed the flow errors on playground, tell me if there's anything else to do

[brentvatne]

@slorber - can you open a PR on the website repo with an API reference for this? http://github.com/react-navigation/website

[brentvatne]

@slorber - it turns out that this isn't a reliable way to find the navigation focused state. it will only work if it is wrapping a navigation screen. if you add it to some component in the screen, and that component is rendered after the parent screen component is mounted, this will not work until you navigate to and away from the screen where it's rendered. this is because it depends on navigation events, and those are only fired when things change. we need some way to be able to reach in to the parent navigation state and determine if it is focused synchronously on mount, in the state initializer. cc @ericvicenti

[satya164]

Maybe a this.props.navigation.isFocused() method will be helpful to get the current focused state? Users can get the initial focus state by using it in componentWillMount

[slorber]

I understand that problem, do you have any solution to propose?

What about a new navigator config withNavigationFocus: true, and making the HOC private/lib internal. This way all screens will be wrapped by the HOC and we can be sure they won't be mounted after the focus event. This HOC makes mostly sense at the root so navigator config can be an appropriate place.

@satya164 I wouldn't use such isFocused function. I've used such child component querying parent from function prop and this get really confusing because if you use this on render (and be certain people will try that) you will be confused because the component won't render on focus change if the component is pure and function is stable. I tricked myself with that in the past.

[satya164]

Another option is to always call the listener with the current value synchronously as soon as you attach it.

[slorber]

I like this idea (it's what History.listen does to provide immediate history location), but shouldn't we create a onFocusChange or something instead of calling didFocus immediately?

[brentvatne]

I don't like calling didFocus immediately, this leads to IMO some confusing behaviors. I also don't like calling onFocusChange to solve the problem that I mentioned above because it's semantically incorrect. We should just expose isFocused(), and initialize the withNavigationFocus state from that.