Modernizing and using flowtype

[beaucollins]

Builds off of #56

• adds flow type
• cleans up channel to remove use of internal methods to use this context.
• Starts removing uses of .bind

[dmsnell]

is there any way to do this in pieces or is the plan to make the changes all at once?

[beaucollins]

We can do this in pieces, I thought I would publish this since we started tackling the same stuff. I was trying to see how flowtype would fit into the project an started fixing all the things it started giving me errors about.

[dmsnell]

why not standardize on a Promise interface? that would let people more easily use async/await too

[beaucollins]

Thats the goal, this is just keeping backwards compatibility right now.

[dmsnell]

sidenote: I find this extremely helpful. the hardest part in reading through this code or in the Simperium server's code isn't know when a type is invalid, but knowing when a collection of properties is supposed to be a given type, or knowing what properties to supply when a hidden remote function expects certain ones.

[beaucollins]

I hope with fully defined jsondiff types this will shine a blazing light on all expected properties in the diffing/syncing magic.

[dmsnell]

for funnies check out the utility types

const operations = {
  Modify: 'M',
  Remove: '-'
};

type Operation = $Values<typeof operations>;

something like that

[roundhill]

The linter is complaining about a few things:

node-simperium/src/simperium/bucket.js
   61:2   warning  Mixed spaces and tabs                    no-mixed-spaces-and-tabs
   84:30  error    'Bucket' was used before it was defined  no-use-before-define
  157:15  warning  There must be a space inside this paren  space-in-parens

Looks like some class definitions need to be moved around and some spacing cleanup.

[roundhill]

I switched this to merge with master since I merged #56 already.

[beaucollins]

For this:

   84:30  error    'Bucket' was used before it was defined  no-use-before-define

When it's class definitions it shouldn't be a problem so we could eslint-disable-next-line

[roundhill]

When it's class definitions it shouldn't be a problem so we could eslint-disable-next-line

WFM, but we'll need to add that 7 times in channel.js

[beaucollins]

I had considered moving type definitions for the main components into it's own file which fixes this problem.

I think the goal is to break this PR into smaller pieces too.

[beaucollins]

#62 is the beginning of a smaller portion of this PR.