Wire up redux and react-navigation

[brettdh]

Initial bare-bones experimentation to get something working. Very rough;
will change considerably, soon. The next iteration will actually have some
sample Redux code to close the loop on how some simple app activities
(such as logging in) will get accomplished using actions and reducers.

Also missing lots of documentation, sadly. Will try to get to that tomorrow.

Main design decisions that I'm proposing (feedback welcome):

• Use React Navigation for app navigation
• Use Redux to store all application state
  • Unless there's a clear reason to put something elsewhere
  • This includes navigation state
• Use the Ducks approach to organizing state management code
  • But more specifically, duck folders
• Use redux-thunk for async actions
  • At least to start.
  • I really want to try out RxJS and redux-observable but that seems like a large learning chunk to bite off for a team with a lot of people new to Redux. (Feel free to tell me I'm wrong about that, though.)

[brettdh]

Note: I had to disable the Flow pre-commit check, because it was checking react-navigation itself, which introduced well over a hundred errors. I imagine there's a way to suppress that; I'll make an issue to look into that later.

[wittjosiah]

I was able to run this successfully and it works like you would expect. Pretty much everything looks fine to me. One thing I would say is that I think its best to avoid eslint-disable-next-line if possible, so if there's gonna be a bunch of those then might want to consider making it the general rule.

[brettdh]

Opened #10 for the Flow issues with react-navigation.

[brettdh]

One thing I would say is that I think its best to avoid eslint-disable-next-line if possible

I agree in general. In these cases, I used it for a few specific rules, so let's enumerate and discuss them here:

1. react/no-typos
   • This is due to a bug: no-typos: false positive jsx-eslint/eslint-plugin-react#1607 but I will try a quick workaround.
2. react/forbid-prop-types
   • This is to avoid a complaint about using the object PropType. I will try again to fix this.
3. import/prefer-default-export
   • I think these will go away as we add more actions, etc. I would be okay with disabling this rule globally, since I think it's reasonable to create a module and anticipate that it will eventually have more than one named export. I also think it's better to create the export as you intend it in that module, so that you don't have to change how it's imported later when you add a second named export.

[brettdh]

Unfortunately, the bug in eslint-plugin-react means that the rule disallows all custom prop types, since they're not in the list that the prop-types lib exports. This seems like an oversight in the rule implementation, but besides this issue, it seems like a very useful rule, so despite the duplication it causes, for now I'm just not creating custom PropTypes.