-
-
Notifications
You must be signed in to change notification settings - Fork 420
Closed
Description
Handling lists in Cycle is hard. It's the only sad thing about Cycle in my opinion so far, specially because lists are so common. Otherwise, Cycle is beautiful. Because it keeps on popping up so often, let's take it a bit more seriously. This issue is to track progress being done to update docs (cycle.js.org), Nick's library Cycle Collections, and other initiatives that may help people feel comfortable building lists in Cycle.js.
There are 4 solutions, here are their pros & cons:
- Manually build the dataflow, which will contain circular dependencies. This is what we do e.g. in TodoMVC.
- Pros: explicit, no magic; follows Cycle.js principles of dataflow and purity; is being improved if people use xstream, it's easier to do that in xstream than it is with RxJS.
- Cons: hard to understand and be comfortable with; probably a bit verbose.
- Wrap the Cycle.js subapps as Web Components https://github.com/staltz/cycle-custom-elementify
- Pros: easier for most web developers to understand; explicit, no magic; enables Cycle.js subapps to be used outside Cycle.js;
- Cons: subapp cannot have effects besides DOM-related; Diversity-support is annoying; Web Components spec is still in flux or not official yet.
- Global state at the top-most component (main).
- Pros: a bit simpler and familiar mental model (like Redux); still aligned with Cycle.js principles of dataflow and purity.
- Cons: still some circular dependency machinery to set up; not fractal, but if you know the tradeoffs, this may not be a problem at all.
- Stanga and similars.
- Pros: Like the above, but circular dep machinery is hidden and automatically managed; is fractal; lenses API as a plus.
- Cons: not aligned with Cycle.js principles of dataflow and purity with regard to drivers, harder to reason about what should be in a driver and what should not be.
- Cycle Collections, the library Nick is working on.
- Pros: aligned with Cycle.js principles, easier to understand the API and reuse, not so much boilerplate/verbosity.
- Cons: "magic", you give it X and Y and "things just work".
- Cycle Onionify, https://github.com/staltz/cycle-onionify
- Pros: fractal with "lenses/cursors"-like API, only one state tree, hides away both
fold
andimitate
, removes props vs state dichotomy. - Cons: currently only xstream support. No props vs state may lead to undesireable concurrent state modifications between parent and children.
- Pros: fractal with "lenses/cursors"-like API, only one state tree, hides away both
mspoulsen, Widdershin, niieani, tusharmath, craigmichaelmartin and 11 more