migrate to pillarjs/router

[wenzowski]

I'm wondering if the vendored express 3 router hack @nateps put together could be replaced with something maintained? It's not that there's currently anything wrong with the vendored code per-se but with maintenance of express 3 being dropped this summer, it would be nice to migrate to something else before then.

Judging by pillarjs/router#14 browser compatibility for the express 5 router will likely be maintained. Note ongoing work in wesleytodd/nighthawk is referenced by that issue.

[wesleytodd]

If you guys are interested in collaborating let me know. Nighthawk is working pretty well for my company and in a few of my side projects, pending this stuff for browser support. So if you are interested in doing something similar it would be better to pool resources in true OSS fashion.

[wesleytodd]

FWIW, I was unfamiliar with this project, so I perused the code a bit. I can see that this is pretty specific to what you guys are doing with Derby as a whole, so totally understand if you don't want to centralize on a more generic solution. But I'm still open to it if you think it is feasible

[nateps]

@wenzowski good find. Thanks for scoping this out.

At a minimum, I'm definitely switching to pillarjs/router, since maintaining my own fork of Express's router makes no sense.

@wesleytodd Just read through nighthawk. There is a lot of overlap, and I think combining efforts would be awesome. Tracks was meant to be a standalone library originally, though I don't think anyone is using it that way at the moment. I'd rather not have to maintain tracks on my own and writing a routing library isn't the primary purpose of my work on Derby. Wrote it way back in the day, since I didn't find anything else like it a few years ago. I'd be all for coming up with something generic that would work for both of us.

There are a number of features that I'd need in addition, and there are some differences that would need to be resolved. I'm planning an overhaul of the API anyway, so now would be a good time to work through it if you want to pair up.

[wesleytodd]

@nateps Yeah, there is a bunch of overlay. Things like intercepting links and all the History stuff can be pulled out for sure. The stuff that I am not really interested in is the form intercepting stuff. That is more up a frameworks alley, like Derby, but not what I need in my basic apps.

It might be best to start by pulling out things like the click handler out then see where it leaves us.

Also, I am not sure if your supports the hash routing stuff, I know you mentioned in that other ticket that you support IE9. But I am really not interested in supporting that feature.

[nateps]

Agreed that pulling out the common parts is probably the best way to
approach this. Should definitely have a module for the click overloading,
which is one of the more complex parts of both tracks and nighthawk.
Noticed a lot of similarity as well.

I'll probably start on a fresh write of tracks with the API that we want,
and then we can turn all of the common parts into modules.

We don't do hash routing and don't intend to. Derby does server side as
well as client side rendering for everything by default, so browsers
without pushState simply fall back to server rendering, which I think is a
much better way to do progressive enhancement.

On Wed, Apr 22, 2015 at 5:59 AM, Wes Todd [email protected] wrote:

@nateps https://github.com/nateps Yeah, there is a bunch of overlay.
Things like intercepting links and all the History stuff can be pulled out
for sure. The stuff that I am not really interested in is the form
intercepting stuff. That is more up a frameworks alley, like Derby, but not
what I need in my basic apps.

It might be best to start by pulling out things like the click handler out
then see where it leaves us.

Also, I am not sure if your supports the hash routing stuff, I know you
mentioned in that other ticket that you support IE9. But I am really not
interested in supporting that feature.

—
Reply to this email directly or view it on GitHub
#22 (comment).

[wesleytodd]

We don't do hash routing and don't intend to. Derby does server side as
well as client side rendering for everything by default, so browsers
without pushState simply fall back to server rendering, which I think is a
much better way to do progressive enhancement.

Awesome, I agree completely. We use React to do the same thing.

[dougwilson]

Hey everyone, in case you were looking for more info on the router module, it will actually be a dependency of Express 5 itself, so will be pretty code and maintained for a long time to come.