Further readme improvements

[goshacmd]

• sections specifically tailored to users of other side-effect management libraries
• assure it's ok to use redux-cycles and something else side-by-side
• simple stream/sink/source/epic definitions to the cycle.js section
• table of contents
• hacked together a quick logo

One thing I think we should settle on is what we call each individual program: a cycle, an epic, or something else.

• Cycle kinda sounds nice, and is part of our new name but... I worry it might be easily conflated with Cycle.js the library
• Epic is a word familiar to redux-observable users

[lmatteis]

I guess we can call them "cycles" (since we have combineCycles). The difference with other Cycle.js functions is that our "cycles" MUST accept ACTION/STATE sources and MUST return an ACTION sink of standard flux actions (perhaps we need to add this somewhere in the docs).

EDIT: good point that it might be confusing with Cycle.js - not sure.

[goshacmd]

@lmatteis I don't think every cycle must make use of and/or return ACTION. Some cycles like analytics, will be only action-in only. Others might be action-out only. And with custom drivers, it's also possible to have cycles that don't operate on ACTION at all

[lmatteis]

@goshakkk true. in fact combineCycles is generic enough to be used outside this project. I'm not sure about giving them a name then. Perhaps cycles is enough. We don't have to have a name like 'epics'. They're just functions that take sources and output sinks - Cycle.js should decide on what to call them

[goshacmd]

@lmatteis thing is, they are called "components" in Cycle.js but to me it looks like an artifact of it trying to take over the DOM, which I'd imagine will be both confusing to React developers, and in a way far from reality.

Cycle for pure side effect management needs another word... so the question is, what's it gonna be. I still fear "a cycle" / "cycles" is going to be inevitable confused for the library itself...

[lmatteis]

I don't see what's wrong with "cycles". We need the connection with Cycle.js - they're Cycle.js functions after all. How are they different from normal Cycle.js functions? In fact, you should be able to totally reuse your cycles in other programs that don't use redux-cycles.

[nickbalestra]

cycle.js provide a cyclic architecture, therefore the name. Cycles make total sense to me. They are nothing more then cycle.js app, mainly just functions. If we don't want to call them cycles as we fear it might create confusion with cycle.js (not sure about it) here few options:

• functions & combineFunctions
• mains & combineMains (cycle convention, not sure I like it in this case)
• not sure about epics, as we want to avoid confusion I'll also try to avoid confusion with redux-observables.

I still think that cycles are pretty appropriate...

[goshacmd]

Ok, I guess we can go ahead with cycles for now, and resolve it later if it ends up being confusing.

[nickbalestra]

What is your point on how we use 'main' for example (...use createCycleMiddleware() which takes as first argument your main Cycle.js...) Is this clear? Should we instead use root as it is more common redux word?

[lmatteis]

I'm also thinking that we can define a "cycle" as a function that takes at least 2 sources (ACTION & STATE) and it MAY return to a writable ACTION sink. This is what sets cycles apart from normal Cycle.js functions imo.

Regarding the wording for "main", I'm not sure because main is what is used in the Cyclejs community. Perhaps it's a rootCycle given the definition above?

[nickbalestra]

Yup I like the cycle defition you provided! And yes now that I think about main, it make sense (not just cause it's beein used in the cycle.js community)

[goshacmd]

Updated the cycle definition in the PR, and swapped the logo. Good to merge?

[nickbalestra]

@goshakkk As I added the drivers parameter to be optional you may want to rebase and make sure that part still there. After that is good to go for me