axefrog / cycle-router5

A router driver for Cycle.js, wrapping the router5 library
29 stars 4 forks source link

Provide more extensive example #4

Open ivan-kleshnin opened 9 years ago

ivan-kleshnin commented 9 years ago

I found one example which uses this library: https://github.com/basham/cycle-demo/blob/router5/src/main.js

There is such search of route handler in the plain Array:

function model(actions) {
  return actions.transition$.map(({toState, fromState}) => {
    // Since Router5 doesn't allow arbitrary data to be forwarded through it,
    // find the original route object and initiate its handler.
    let routeName = toState.name;
    let route = routes.filter(({name}) => name === routeName)[0];
    let handler = route.handler();
    return {routeName, handler};
  });
}

Which seems not correct as routes can be nested and the thing that we need to look for handler kinda undermines the router purpose.

It would be great to know how do you see an idiomatic way to react on route changes.

router.addListener() line makes me stuck because Router5 examples are heavily bound on Listeners and we provide no listeners here. Listener argument isn't optional in the original Router5 API and it's kinda hard to understand what to do next. My first thought was that we need to provide some listener function there to start, but then I found an example above...

axefrog commented 9 years ago

I made this driver having only experimented router5 at a basic level, but haven't had a chance to go deeper due to a deadline with a client's website, so the best guidance I can offer is that I tried to simply wrap what router5 had to offer, while segregating asynchronous methods from synchronous methods to try and work them into cycle's source/sink driver pattern. Beyond that, I haven't had a chance to think about it more deeply, so I'm pretty open to community input on any architectural issues with the code as it currently stands.

That all said, my preliminary thoughts on the matter are that, first of all, router5 exposes 3 primary listener methods, and those are all exposed by the driver, so you can listen to any of them depending on your needs. If you want to react to changes to subnodes, it would be trivial to call router.areStatesDescendants(parentState, childState) to determine the hierarchical relationship between the old and the new state. Because this is a synchronous method, you'd call it from the driver source object inside an rx filter, I guess. The previous version of the driver didn't include that method though, either because it didn't exist at the top, or I just missed it.

I've just updated the driver to use router5 version 0.5.0, and exposed the areStatesDescendants method. There are some other new methods relating to transition events, but I haven't had enough time to consider how best to wrap them just yet. You're welcome to submit any pull requests to that effect.

ivan-kleshnin commented 9 years ago

I see. Thank you for explanation. I'm going to experiment with this library for few days to see how it's going. I'm also new to Router5, but it seems more elaborated than alternatives, so I'm glad that you've picked it.

axefrog commented 9 years ago

No worries, let me know if you have any further thoughts after you've used it a bit.

axefrog commented 9 years ago

Whoops, didn't mean to close this.