Collaboration with cycle-restart

[Widdershin]

Hey @whitecolor!

This is such a cool project.

I think users might be confused between what this does and what cycle-restart does, so I'm going to first outline how I think the various approaches work (please correct me if I'm wrong), and then how they might work together.

Normal HMR (with browserify-hmr or webpack and no libraries)

When the code is changed, the entire application is restarted. However, it's up to the user to include some configuration in their app to stop the old code and start the new one. Functionally equivalent to reloading the page and starting the app from scratch with the new code, minus the page reload.

const {sinks, sources} = run(app, drivers);

if (module.hot) {
  module.hot.accept();

  module.hot.dispose(() => {
    sinks.dispose();
    sources.dispose();
  });
}

cycle-hmr

Comparable to the above approach, except that when you change the code, only the components that use that code reload. The newly reloaded components will have their state reset, but the rest of the application state will remain intact. This is achieved by using a babel plugin to wrap all exported Cycle components in such a way that we can update their code on reload.

cycle-restart

Designed to be used with the normal HMR approach. Doesn't actually do anything to hot reload your code, but is designed to solve the problem of application state being reset after reload. Achieves this by keeping a log of all incoming events (sources) and then replaying them after the code is reloaded. Functionally equivalent to reloading the page and performing all of the same actions again, minus the page reloading and manually performing the actions.

(currently) requires the user to include some boilerplate configuration. Also (currently) coupled to Rx although this is not fundamental to cycle-restart's design.

const drivers = {
  DOM: restartable(makeDOMDriver('.app'), {pauseSinksWhileReplaying: false}),
};

const {sinks, sources} = run(app, drivers);

if (module.hot) {
  module.hot.accept('./src/app', () => {
    app = require('./src/app').default;

    restart(app, drivers, {sinks, sources}, isolate);
  });

Conclusions

Please correct me if I'm wrong, but as far as I understand cycle-hmr and cycle-restart solve different problems. cycle-hmr takes the place of "normal" hmr, and cycle-restart is just about replaying actions so that state is maintained.

It seems like we could potentially use cycle-restart in conjunction with cycle-hmr. There's no reason why the log/replay approach which is currently applied just to your main function couldn't be applied on a per component basis.

What do you think? Seems like we have a good opportunity for collaboration here.

[wclr]

@Widdershin Yes cycle-hmr utilizes kinda "standard" approach - replacing internals of existing instances with new coming versions.

As I see it cycle-restart approach more refers to time travel and debugging tools like https://github.com/gaearon/redux-devtools. But you try to be general purpose with replay. I'm not sure currently that it viable approach for practical usage if go too general. I think replaying the app (or component) should be more specific actions/state oriented - but I may be missing something for now.