Better structure and refactoring about zulip-mobile

[neerajwahi]

@borisyankov why add container components?

[borisyankov]

Mostly for separation of concerns. Sometimes for better reusability, but not always.
I've also used before it to convert from Immutable to plain JS objects, but not sure it was consistently a good idea.

Generally a container will take care of retrieving the data (from Redux, via fetch, etc.) but will just render a single component. The behavior and view will be in this component, but it will be 'dumb' about where the data is coming from.

Some of the ideas come from:
https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0#.fakt3m8o4
and some from other discussion places and personal experience.

[neerajwahi]

I think we can wait to do this kind of refactoring until it becomes a bigger problem. Thoughts?

[neerajwahi]

Also, I'm not sure it's worthwhile to add Flow types to the API calls. Flow is a static type checker but the API results are dynamic, so it won't really be able to do any checking with those types.

[borisyankov]

@neerajwahi Yeah, I wanted to document the goals more than necessarily put it as priority.
New stuff will follow this, but not going to rework everything that was written (did the Zulip removing because it was trivial)

[borisyankov]

Closing as 'complete'.