Version 1.0, huge refactor and re-write of pieces

[mrozbarry]

What

This PR represents the changes needed to align better with TEA (the elm architecture), and to be usable in real world applications. This also includes better and more tests, bumping up to 100% line coverage.

Breaking changes

• No more middleware.
• No more results

Bug Fixes

• Fixes issue where delays weren't being stacked by introducing new core effect, ferp.effects.thunk(method).
• Fixes inconsistent message and millisecond ordering between subscriptions.every, effects.delay and effects.raf.

Enhancements

• Rewrites effects and effect runner.
  • Adds ferp.effects.thunk(method).
• Test coverage increases to 100% of lines, and 70%+ of statements and functions.
• Adds ferp.util.combineReducers to manage deep nested reducers that return effects.
• Adds CHANGELOG.
• Documentation updates.
  • Adds section to main README explaining how data flows through the app.
  • Updates documentation to use new effects.
  • Documentation on best practices for testing apps written in ferp.
• Add tests to examples:
  • Cli examples:
    • Effects timer
    • Subscription timer
    • File reader
    • xhr request
  • http server
  • superfine integration

Notes

Removing middleware

The current implementation of middleware allowed implementations to completely change the behaviour of ferp and the flow of effects, messages, and state. I attempted to build a functional alternative that I called listeners, but felt it didn't really feel like a functional approach. After a few days of thinking, I opted to completely remove this mechanism - it was not a fit for the library, and just added an extra layer of complexity/debugging.

Most middleware that I have thought of ends up feeling like they should be an effect, and in fact, the only middleware that I could justify was simply a logger that would output the message, and updated state, but this is only really useful in debug/early development of an application.

For these reasons, the mechanism has been removed. You can see examples of a high-order function logger in examples/cli if you find it necessary for debugging.

Removing results

I really liked the idea of result, being a hybrid of Elm's Result and Maybe types. The problem is that it's a type; since I don't really have control over javascript, the result type isn't enforceable. Having something that reflects how Elm and other languages deal with nulls or async data states is neat, but I don't think it should be a core feature, especially because it is opt in. No internal code uses the result type, and my singular example of it was contrived.

The code is hard to justify, too, considering anyone could just npm install lodash.get and have something akin to Maybe support by using the default param.

The code currently still exists in the latest push, but I have intentionally removed it from being exported until I can make a better decision on what I want to do with it. (update Sept 30, 2018: I removed it for now). Input welcome.