I've been toying with routers inside of cycle for a little bit, and there has been some good discussion and work over at https://github.com/router5/router5/issues/5

But I think there is some discussion needed on what an ideal router driver API should look like.

My initial thinking was the following:

makeRouterDriver(routes, options) {
  // create router
  return routerDriver(namedRoute$) {
    // magic
    return context$
  }
}

where namedRoute$ could be an observable of string values like: "home" and context$ could be an obserable of a context object:

{
  path: '/users/4',
  name: 'users',
  params: {'userID': 4},
  etc.
}

I also assumed that the routes setup should be passed to the routerDriver constructor, however, as @staltz commented in the aforementioned router5 issue, that this might not be the optimal solution.

TL;DR: create a Signals library besides xstream, use it as the expected sink in some drivers

Problem

Over the weekend in CycleConf 17 we started discussing how to better accommodate usage of inherently pull values like Math.random() or window.outerHeight into Cycle.js apps in a way that follows the framework's way of working.

Currently you would have to do something nasty like click$.map(() => Math.random()) which is impure but most importantly, makes testing a bit worse since it's non deterministic and we're not into doing invasive mocking of globals.

I noticed a similarity between these values, is that they all look like () => T, e.g. Math.random(): number. Then I drafted this on a paper:

• PURE: f(x: A): B
• PUSH: f(x: A): void (used for sending events e.g. observer.next(ev): void)
• PULL: f(): B (used for reading values)
• SINK-ONLY DRIVER: f(x$: Stream<A>): void
• SOURCE-ONLY DRIVER: f(): Stream<B>
• MAIN (or what @TylorS calls component): f(x$: Stream<A>): Stream<B>

Most of these bullet points are covered in Cycle.js, except PULL. That's how I noticed it was a missing piece. After discussing with others, watching a talk by Erik Meijer, revising the Push-pull FRP paper by Conal Elliott, I noticed we just need to have a functional ES6 Iterable library. For a while I investigated Dominic Tarr's pull streams and came to the conclusion it's basically AsyncIterable as per Erik Meijer. For a while we also got quite worried about polling given what Conal Elliott described as the biggest problem with pull collections to represent continuous values over time. We thought if there should be a push-and-pull collection (e.g. to represent the virtual DOM over time, which is a "continuous" value which emits updates), and noticed that perhaps Derivable.js by David Sheldrick or Menrva could fill that gap.

Then, @Widdershin suggested we might not even need a push-and-pull hybrid for the DOM Driver if we have an entirely pull-driven approach with requestAnimationFrame polling. Nick suspected it would be even more better than the current reactive approach.

We started hacking and came with a proof of concept here: https://github.com/staltz/experiment-push-pull-cyclejs

function main(sources: Sources): Sinks {
  const vdomS = sources.windowHeight.map(height =>
    div('.foo', 'Height: ' + height),
  );

  return {
    DOM: vdomS,
  };
}

run(main, {
  windowHeight: () => Signal.from(() => window.outerHeight),
  DOM: makeDOMDriver('#main-container'),
});

Notice the new convention x$ is a Stream and xS is a Signal.

The example works with rAF and demonstrates that we could essentially model values-over-time as signals, with the same type of functional composability with operators as in xstream or rx.

What next

Having Streams and Signals in Cycle.js would be a revolutionary change that requires a lot of careful planning. We don't want to find a show-stopper and be embarrassed after launching this change. For now we have no guarantee whatsoever that this will actually be a thing in Cyclejs.

Publish the signal library as a standalone ysignal in release candidate or v0.x for wild experimentation. ysignal should be "hot" in the same sense as xstream because we need the assumption of "one execution per stream" and "one execution per signal" so that the DevTools dataflow graph displays something that makes sense in people's mind. A hot Signal (implements Iterable) would mean there is a shared Iterator which is lazily created and destroyed with refCounting.

We need to consider should we remove MemoryStreams from xstream because so far it has been used to represent values over time, and with Signals we wouldn't need MemoryStreams anymore. Currently MemoryStreams are pull on subscribe, push afterwards, so they have a pull ability. With Signals dedicated for pull, we might not need to mix pull and push. We can have Streams only for push, and Signals only for pull.

xstream and ysignal could be tightly interrelated "sibling" libraries if they have conversion operators from one to the other and vice-versa. Not sure if they should do that, or if they should just assume conversion with Iterables and ES Observables.

On the topic of conversion, I noticed Push-to-Pull then Pull-to-Push is not an isomorphism. I don't know what to call that in category theory but all I'm saying is that when you go from Push to Pull, the Pull producer can choose what and how much data to replay, and when you go from Pull to Push, the Push producer can choose when to emit data. This liberty of choice means information is lost during conversion.

We need to investigate further if we need a hybrid type in Menrva/DerivableJS style. Related to that, since those libraries do intelligent computation of derived values in the signal graph, we might need that ranking algorithm (maybe we don't need the Push part of being hybrid).

We could map what drivers would expect Signal sinks and what drivers would expect Stream sinks.

DOM Driver isolation and event delegator event Streams based on Element Signals may be a challenging problem.

Need to also consider how to support stream lib Diversity.

Nick Johnstone could comment on his ideas how to use this with cycle/time.

I just started playing with Cycle and it looks really cool!

To me, two things immediately surprised me, so I was wondering if I'm missing something.

1. interactions.get(selector, eventName) in all examples I've seen pass in a selector (not a dom element) which means those selectors are queried globally in the entire DOM. Surely this is really impractical, you want to scope it all down to specific components, the way you can easily do with React's inline handlers? Wouldn't it be better if say you handle events in the view and then emit to the interactions stream the low level event or a higher level intent?
2. registerCustomElement seems to register elements globally. Again, this is, imho, mush inferior to how something like React does it where you require components and use them by reference. Is there a way to do that in Cycle? `var Button = require("./button"); Button({}). Sorry if this is documented somewhere, I couldn't find an example/docs.

This idea: https://gist.github.com/axefrog/e53b915b1ddd37ce1eac

Need to let cool down, experiment with it, and evaluate whether 'benefits minus magic minus boilerplate' is positive.

My main issue with the current Cycle architecture is the way drivers are actually globally scoped:

• DOM.select('.field') looks for an element in the whole DOM subtree managed by Cycle
• HTTP is the stream of all HTTP requests/responses going through the driver

The developer has to be aware of this and take extra precautions to filter out other inputs, such as other parts of the DOM also matching the selector, or other requests issued by other bits of the app.

The HTTP and fetch drivers encourage filtering the stream of requests by URL or name, but that solution is suboptimal because it could easily suffer from clashes if other components requested the same URL or used the same identifying name. Put otherwise, there is no strong guarantee of isolation.

The better, driver-agnostic solution to this problem is isolate (provided the driver implements isolateSource/isolateSink -- the fetch-driver doesn't for example).

It could be argued the implementation of isolateSource/isolateSink is somewhat inelegant compared to the rest of Cycle, with the HTTP driver patching a _namespace property on the request, and the DOM driver writing class names that end up in the DOM (see https://github.com/cyclejs/core/issues/226), but I guess these are mostly hidden away from users.

However, shouldn't isolation be default behaviour, possibly with an opt-out, rather than being opt-in?

Anecdotally, of all the people I talked to this about, no-one had realised that sources.DOM.select(_) was not scoped to the virtual-dom subtree returned by that component.

I really love the concept of fractal architecture @staltz is striving for, but I would argue one of the key benefits is to reduce cognitive load and complexity for the developer by allowing local reasoning, without side-effects. Without isolation, there's a persistent risk of global "side-effect" (in the broad, non-FP sense) and hard-to-debug collisions between distinct parts of the system.

Another way to phrase this is: when is isolation not desirable? Surely, components should always be isolated, unless they rely on side-effects (watching DOM they don't own, catching requests they didn't issue), which is antithetical to the whole concept.

These practical concerns aside, I'm also curious about the performance and scalability implications of having such centralised management of streams. Are there benchmarks of how this scales up to thousands of components, with hundreds of subscribers to the HTTP driver requests stream and thousands to the DOM driver events streams, recursively calling the isolateSource and matchesSelector for each level of the component tree?

I'd like to make it clear that I still think Cycle is a fantastic idea, and the reason I raise this is because I'm worried this could get in the way of its success.

To make this a more constructive criticism, I've also played with an alternative DOM driver API that keeps effects local. I've put it up in a repo on GitHub, in the hope it can spur discussions on alternative solutions to this issue.

I admit I was also trying to make observed events more explicit in the component sinks, rather than relying on .events() on the sources and manually matching class names in the .select(_) and outputs. However I'm interested to hear what people think, what principle I have violated doing so, and what may be wrong with this approach :smile:

/cc @jamesgorrie @kenoir @phamann @oliverjash @jackfranklin who I discussed this with in the past few weeks.

@TylorS and I started discussing how to migrate to RxJS 5, and/or support most.js streams without the need for a fork (Motorcycle.js) which mostly has copy-pasted code from some Cycle.js libraries.

We arrived at a proposal: Build a "base" run() function which is generic and assumes no stream library. It uses "stream adapters" to agree on an interface for each stream library. We need to build an adapter for each stream library. We also need to build "rx run()", "most run()" which basically utilizes the common "base run()" but specify which stream library adapter is used. Drivers are given the stream adapter object from run(), and can written using whatever stream library.

@cycle/rx-run

import baseRun from '@cycle/base'
import streamAdapter from '@cycle/rx-adapter'

const Cycle = {
  run: (main, drivers) => baseRun(main, drivers, {streamAdapter})
}

export default Cycle

@cycle/dom

function domDriver(sink$) {...}

domDriver.streamAdapter = rxAdapter // mostAdapter 

Tasks to do

• [x] Create @cycle/base repo (essentially this PR #198 there) https://github.com/cyclejs/base
• [x] Write test for @cycle/base ensuring one-liner drivers work properly with default adapter.
• [x] Build https://github.com/cyclejs/rx5-adapter with tests, using StreamAdapter interface from base
• [x] Build https://github.com/cyclejs/rx4-adapter with tests, using StreamAdapter interface from base
• [x] PR on Cycle Core to implement it as @cycle/base + @cycle/rx-adapter, with #200 in mind
• [x] Make canary version for core
• [x] Make @cycle/rx-run npm package alias for @cycle/core
• [x] Rewrite Cycle DOM Driver in TypeScript with transposition off by default
• [x] Update base to export CycleSetup interface
• [x] Fix Cycle DOM diversity to adapt the out-facing streams for the app's stream library
• [x] Convert some cycle-examples to use the canary version of dom with RxJS 5
• [x] Cycle HTTP driver in TypeScript and using driverFn.streamAdapter = rxAdapter
• [x] Make canary versions for http, test it around
• [x] Update power-ui to Diversity
• [x] xstream-adapter
• [x] xstream-run
• [x] Fix Cycle DOM last bugs with DOMSource.events() and isolate
• [x] Soft release core, dom, *-run, http, jsonp RC versions
• [x] Build https://github.com/cyclejs/most-adapter in JS with tests, using StreamAdapter interface from base
• [x] create @cycle/most-run https://github.com/cyclejs/most-run with #200 in mind
• [x] Unnecessary: Update motorcycle drivers to use driverFn.streamAdapter = mostAdapter
• [x] Update examples and TodoMVC to Diversity & xstream
• [x] Make bmi-typescript example, and fix Cycle DOM TypeScript problems, issue #307
• [x] Write http-random-user in TypeScript to make sure HTTP Driver is also working well
• [x] Change HoldSubject to Subject in stream adapters. It's not needed.
• [x] Rework makeHTMLDriver(callback)
• [x] mockDOMSource should return a stream of the app's own stream library.
• [x] DOMSource.select().elements should return WhateverStream interface, not type any
• [x] foo-adapter and foo-run: remove dispose(), add remember()
• [x] Update cycle history to use stream adapter remember()
• [x] Update TodoMVC using cycle history
• [x] Fix Cycle DOM documentation generation
• [x] Update cycle.js.org
• [x] cycle.js.org documentation page
• [x] Write Release notes and migration guide
• [x] Merge branches diversity to master, and publish non-rc versions
  • [x] Cycle Core / Rx Run
  • [x] DOM
  • [x] HTTP
  • [x] JSONP
  • [x] examples
  • [x] cyclejs.github.io
  • [x] others
• [x] npm deprecate @cycle/core, use rx-run
• [x] Cycle DOM rxjs-typings, rx-typings, most-typings
• [x] Cycle HTTP rxjs-typings, rx-typings, most-typings

Breaking changes so far

• DOMSource.select().observable => DOMSource.select().elements()
• new Cycle.run API for those cases where sources and sinks are wanted: #200
• Snabbdom instead of virtual-dom
  • breaking changes with hyperscript way of using attrs
• top-level <svg> element is created with hyperscript-helpers but children elements created with hyperscript
• mockDOMSource(sa, config) now takes a Stream Adapter as the first argument
• makeHTMLDriver() => makeHTMLDriver(effectFn, options)
• No more onError callback as an option to makeDOMDriver()
• No more sinks.dispose and sources.dispose
• HTML Driver returns and HTMLSource mimicking DOMSource. HTMLSource.element$ is the stream of HTML strings
• HTTP Source is not response$$ but contains it. It's an object with select(category: string): Observable<Observable<Response>>, filter(predicate: (res$: ResponseStream) => boolean): HTTPSource and response$$ property.

As per discussion, sometimes the way that dialogues are developed can introduce an awkward feedback loop.

Per @staltz' example

  const proxyTextFilterSinks = {value$: new Rx.Subject()};
  const actions = intent(proxyTextFilterSinks);
  const state$ = model(peoplePageHTTP.response$, sources.props$, actions);
  const textFilter = TextFilterWrapper(state$, sources.DOM);
  replicateStream(textFilter.value$, proxyTextFilterSinks.value$);

The development of a babel plugin could potentially ease this pain, and doesn't require the writing of an entirely new language.

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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".
6. Cycle Onionify, https://github.com/staltz/cycle-onionify
   • Pros: fractal with "lenses/cursors"-like API, only one state tree, hides away both fold and imitate, 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.

CC @Widdershin @laszlokorte @milankinen @TylorS

We could generalize interactions with external systems, and make the user interaction to be just one of those interactions. For instance, human-computer interaction happening simultaneously with server-computer interaction.

Proposed API:

function computer(interactions) {
  var userClicks = interactions.get('dom://.target/click');
  var responses = interactions.get('mongodb://foods/3/best-before');
  // ...
  return {
    vtree$, // as usual
    request$ // for mongodb
  };
}

Cycle.apply(computer, {
  dom: '#app',
  mongodb: someMongoDriverHereWithConnectionConfig
});

How about letting isolate accept multiple scopes? So instead of:

isolate(Child, 'child')({onion, HTTP})

one could also do:

isolate(Child, {onion: 'child', HTTP: 'xyz'})({onion, HTTP})

This would solve for instance staltz/cycle-onionify#8:

isolate(Child, {onion: 'child', HTTP: 'xyz'})({onion, HTTP})
isolate(AnotherChild, {onion: 'child', HTTP: 'uvw'})({onion, HTTP}) 

When the scope for a driver is omitted, one would be internally generated, as usual:

isolate(Child, {onion: 'child'})({onion, HTTP})
isolate(AnotherChild, {onion: 'child'})({onion, HTTP}) 

I've already implemented this in a branch.

In addition to this change I also removed the conversion of scopes into strings (e.g. when you provide a number) because I need that for an other experiment with onionify. This can break isolation in some drivers, e.g. in the DOM driver when you pass a number as scope.

I implemented react-hot-loader for React (with core being extracted into react-hot-api) and I think it should be possible to implement the same for Cycle, especially considering its this-lessness.

Would you be interested in helping out with this?

ISSUES CLOSED: #989

• [ ] There exists an issue discussing the need for this PR
• [ ] I added new tests for the issue I fixed or built
• [ ] I used pnpm run commit instead of git commit

Having issues after upgrading history driver to latest version (state not replaced).

Looking to code I see that now input is passed as object to underling history lib

if (input.type === 'replace') {
      history.replace({...input});
}

But remix-run/history still require separate params:

  /**
   * Replaces the current location in the history stack with a new one.  The
   * location that was replaced will no longer be available.
   *
   * @param to - The new URL
   * @param state - Data to associate with the new location
   *
   * @see https://github.com/remix-run/history/tree/main/docs/api-reference.md#history.replace
   */
  replace(to: To, state?: any): void;

Code to reproduce the issue:

for @cycle/http:

http = makeHTTPDriver()(request$, 'fooHttp')

Expected behavior:

This should typecheck.

Actual behavior:

This doesn't typecheck as makeHTTPDriver() returns a function expecting exactly one argument but passed two instead.

Versions of packages used:

@cycle/[email protected]

For anyone come across this, my current workaround is to give drive a more accurate type:

 const driver: ((stream: Stream<RequestInput>, name?: string) => HTTPSource) =
      (makeHTTPDriver() as any)
 http = driver(request$, 'fooHttp')

It looks to me like some of the dependencies for (at least) one of the examples are out of date. Attempting to run npm start in "cyclejs/examples/intermediate/tsx-seconds-elapsed" fails with TypeScript errors starting with:

"node_modules/@types/node/index.d.ts(20,1): error TS1084: Invalid 'reference' directive syntax."

I updated several dependencies by deleting dependency and devDependency lines from "tsx-seconds-elapsed/package.json", and then reinstalling the associated libraries with npm, and the example now builds and runs as expected. I'm relatively new to JavaScript and node.js development, and very new to poking around in Cycle, so I'm not sure—first—how to choose and maintain the versions of dependencies for this example, and—second—what is the best way to manage the dependency listings in "package.json". That said, I've attached the diff to "package.json", if it helps provide some information.

There was a PR that introduced MainDOMSource, BodyDOMSource or DocumentDOMSource as variants of DOMSource union type (https://github.com/cyclejs/cyclejs/blob/master/dom/src/DOMSource.ts#L16)

Usually in the code, we use MainDOMSource as type of DOM source. And document or body sources are available from any normal DOM source are used as: DOM.select('document').events(...).

Explicit use of BodyDOMSource or DocumentDOMSource types is a very rare case only for specific components, and probably even more rare case would be expecting DOM source to be MainDOMSource | BodyDOMSource | DocumentDOMSource (which DOMSource now), even if so explicit statement of BodyDOMSource | DocumentDOMSource would be even more appropriate.

So why this common DOM source it is called MainDOMSource, why not CommonDOMSource or ElementDOMSource, prefix Main probably the shortest option and has some sense but still seems unnatural and contrived here.

So I propose to remove/deprecate MainDOMSource and rename it to DOMSource, removing union type, the rationale for this is to make reference to commonly used DOM source type more simple and conventional, as there is no real practical reason to have a union type for all kind of sources (DOMSource union type itself actually is not used in the driver's code anywhere). So DOMSource would mean normal commonly used dom source which supports isolation and etc., and there will be specific two types BodyDOMSource and DocumentDOMSource which will be explicitly used when needed.

So this is my current perspective on this situation with quite ugly/contrived name MainDOMSource, but maybe I missed something.