What about a knockout router plugin for SPA applications?

[hankir]

For the tko is not enough plugin for routing, transitions, etc. There are many libraries: sammy js, crossroute, etc. but many of them have not been updated long ago. Recently released PagerJS (v1.1.0 https://github.com/finnsson/pagerjs) what you think about this candidate?

[brianmhunt]

Thanks for posting - great suggestion.

The PagerJS model seems like a pretty good tact, and ideally before adding to TKO (which I think is a good idea) some updates could be done, including:

1. Updating to ES6
2. Changing tests to be karma-compatible
3. Remove jQuery/History.js dependencies (with optional dependency on History.js)
4. Use Promises to handle asynchronicity

Those are just some thoughts - I'll need to mull it a bit. 😉

[caseyWebb]

psst... https://github.com/Profiscience/ko-component-router. AFAIK, this is the only maintained Knockout centric router, and it will remain that way as we are heavily invested in Knockout.

Rather than building in transitions and similar features, the router has a "lifecycle middleware" concept that affords you a lot of flexibility for implementing such features.

Here is an example "framework" of sorts based on the architecture we use at our company. Note, it's unfinished, and I'm pretty busy so it hasn't gotten a ton of attention as of late. That being said, it's modular by design and doesn't force you into anything.

@brianmhunt, fwiw, ko-component-router satisfies all of your criteria above. Plus, it's TypeScript, so full bindings are supplied OOTB, and they're guaranteed not to go out of sync. It does have a dependency on lodash, though.

Disclaimer, if it's not obvious, I'm the developer of this package and this is a shameless plug.

[rposener]

@caseyWebb's approach looks very good.

IMO and for sake of discussion - I think this has potential, but not sure it's necessary to be part of the core tko, unless you're really thinking of tko becoming a full framework (like vue/angular)? I like that ko does only 1 thing and that 1 thing well. This feels like it should stay separate. Just like I never start a ko project without pulling ko.postbox as well so that I can use pub/sub between components, I'll continue to pull in my favorite routing framework as well. While both are excellent and useful features, not sure everyone wants either feature as a default/standard. I find this separation/focus the strength of knockout.

I would be 100% in favor of documentation site doing more to point people to tko-friendly resources for other "parts" to build-up a complete framework of your own choosing.

[miellaby]

Integrating a third party router embeds a parallel event/binding logic which predates KO native approach. A good solution should not push the developer to learn new concepts on top of Observables.

By the way, what bothers me with the different routers I've found for knockout is that they are all heavily based on advanced features like components, custom bindings and the like.

My opinion is that routing may and should be a direct application of basic KO features.

My own router class allows something like: <div class="page1-container" data-bind="if: router.p('page1').visibility()"></div>

router.p() is a page factory which creates a page object on the fly. The created page is bound to a synonymous client-side route and a visibility observable is provided so to make if/visible/with binding easy as pie.

I have a few more features, like a "payload", that is a set of key-value pairs in the url. The important point is that everything is based on regular observable/computed concepts.

[revengineering]

I strongly agree with @rposener on this one. The appeal of knockout is that it does one thing (binding markup to data and behavior) extremely well. I'd be sad to see it scope-creep its way to becoming yet another opinionated SPA framework.