Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Simple express-like routing for front-end

github.com

Post reply on HN
Print view View original

1–10 of 28 posts

Re: Show HN: Simple express-like routing for front-end

#3

Post by micaksica »

I'm watching a movie so I haven't looked too deeply at this, but your regexes aren't safe from ReDoS according to substack's safe-regex [1]. It might be worth finding a non-regex-based way to parse regular expressions in case of some weird routes that could cause exponential-time parsing.

[1] https://github.com/substack/safe-regex

Re: Show HN: Simple express-like routing for front-end

#6

Post by franciscop »

micaksica wrote: post #3

I'm watching a movie so I haven't looked too deeply at this, but your regexes aren't safe from ReDoS according to substack's safe-regex [1]. It might be worth finding a non-regex-based way to parse regular expressions in case of some weird routes that could cause exponential-time parsing. [1] https://github.com/substack/safe-regex

The path is preferred to the Regex, and I hope that no developer is using user input to create a route here. As specified in substack's safe-regex:

> WARNING: This module merely seems to work given all the catastrophic regular expressions I could find scouring the internet, but I don't have enough of a background in automata to be absolutely sure that this module will catch all exponential-time cases.

I also don't have it and I think the case for this error is so contrieved that it doesn't make sense to add a check in pagex. So adding a couple of warnings, one for not trusting user input and another for this specific error, should be fine.

Re: Show HN: Simple express-like routing for front-end

#7

Post by franciscop »

lcarlson wrote: post #5

How is this different from page.js?

It was initially a Regex-only project so it was quite different. Then I added path-to-regex and forgot to check if there was some library out there similar so now they are quite similar.

However I can see a couple of important differences:

1. The parameters are passed to the callback in pagex which makes it cleaner:

    pagex('/users/:id/:frag?', function(id, frag = 'profile'){ ... });
While with page.js you have to retrieve them manually:

    pagex('users/:id/:frag?', function(ctx){ var id = ctx[0], frag = ctx[1] });
2. You can negate the url. For instance, if you want something to run in all pages except in the users page:

    pagex('/users', true, function(){ ... });
3. [undocumented, not-official] There is a before and after catch-all which can be useful for debugging, analytics or similar

Re: Show HN: Simple express-like routing for front-end

#8

Post by lcarlson »

franciscop wrote: post #4
urvader wrote: post #2

Do you plan to support middlewares?

Could you explain further, please? I plan on changing it a bit internally but not on growing it past its purpose as I like it to do only one thing (and hopefully do it well)

I think page.js supports middleware if you're looking for something to emulate. Basically chainring callbacks.

Re: Show HN: Simple express-like routing for front-end

#9

Post by franciscop »

lcarlson wrote: post #8
franciscop wrote: post #4

Earlier quoted context omitted.

Could you explain further, please? I plan on changing it a bit internally but not on growing it past its purpose as I like it to do only one thing (and hopefully do it well)

I think page.js supports middleware if you're looking for something to emulate. Basically chainring callbacks.

Only reference I could find in https://visionmedia.github.io/page.js/ was:

    page(callback)

    This is equivalent to page('*', callback) for generic "middleware".
Which is... pointless? If you are going to call a function everywhere in front-end why don't you use an IIFE for scope or just nothing at all? Unless you wanted to put it on the and make it load when the page is ready.

Re: Show HN: Simple express-like routing for front-end

#10

Post by olalonde »

One powerful feature of the Express router (but missing here) is that it's just a middleware, making composition trivial, e.g.:

    const userRouter = router()
      .get('/', showUser)

    const usersRouter = router()
      .get('/', listUsers)
      .use('/:username', userRouter)

    const mainRouter = router()
      .use('/users', usersRouter)
Post reply on HN