Closed goshacmd closed 7 years ago
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.
@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
@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
@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...
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.
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:
I still think that cycles are pretty appropriate...
Ok, I guess we can go ahead with cycles for now, and resolve it later if it ends up being confusing.
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?
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?
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)
Updated the cycle definition in the PR, and swapped the logo. Good to merge?
@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
One thing I think we should settle on is what we call each individual program: a cycle, an epic, or something else.