Opening up the router restrictions a bit

[jwoertink]

Ref: luckyframework/website#717 (comment)

In that thread, @kevinsjoberg and I were discussing the use of route path variables. Currently placing the variable anywhere isn't allowed (e.g. /user-:user_id is invalid). Lucky generally has pulled a lot from Elixir's Phoenix framework as well as Rails when deciding what and how to add things in, but Lucky has no goal to be 1-1 with any other framework. Our top goal first and foremost is catching bugs in development, and one of the ways we achieve this is by enforcing a stricter coding style. The idea here is that you're working on a team on some app, and different devs come in and out over the years. This can lead to people adding code in using their own styles which could potentially lead to inconsistencies or bugs.

One recent feature was the route checks #1536 which ensures all routes use _ underscores to separate words instead of the kebab case with dashes -. (e.g. /getting_started is preferred over /getting-started).

With that said, Rails allows routes like /user_:user_slug(.:format); should the Lucky Router be this flexible as well? My initial thought was "no", but then thinking about it, maybe it wouldn't be too bad to implement...

Let me know your thoughts, and if you have ideas on how we can make it better. What things do you think the router should / should not do?

/cc. @paulcsmith

[hovsater]

I vote for allowing this in Lucky as well. I don't see any immediate benefit in limiting the places a dynamic segment is valid. Perhaps, I'm biased coming from Rails. 😅

I happen to know (a friend of mine work there) that IKEA uses a URL naming scheme along the lines of /:bucket-:id for their media. See https://www.ikea.com/se/sv/p/vardagen-behallare-med-tappkran-80452639/ for an example. It's not a single slug, because the same :id can exist in different :buckets.

I guess one could argue that the Lucky way of doing it would be treating it as a single slug, and then parse it from within the appropriate action.

[jwoertink]

That's definitely a good point. In this case, you're saying that we have a specific action for that bucket like

class Buckets::Product::Show < BrowserAction
  get "/se/sv/p/vardagen-behallare-med-tappkran-:product_id" do
    # ...
  end
end

Could this same example be handled like this?

class Product < BaseModel
  #...

  def to_param
    [bucket.slug, id].join('-')
  end
end

class Buckets::Product::Show < BrowserAction
  get "/se/sv/p/:product_id" do
    # ...
  end
end

link product.name, to: Buckets::Product::Show.with(product)

Assuming a Product belongs_to a Bucket, we can define our own to_param method which will allow us to pass a model instance in to an Action, and get the same result.

My thought was if vardagen-behallare-med-tappkran is dynamic, then it would have to be a variable too, right? But if it's something static, then I could see that needing to be defined in the action.

Side bar: is IKEA built in Rails? 😂 That would be pretty neat.
Side bar 2: I need to go run to IKEA later... 🤔

[hovsater]

The media bucket is dynamic, but there would be static content in-between them, right?

"se/sv/:media_bucket-:media_id"

Assuming a Product belongs_to a Bucket, we can define our own to_param method which will allow us to pass a model instance in to an Action, and get the same result.

I think this is fair compromise when all data is modelled in Lucky itself. However, there might be cases when the variables capture information used by a third-party, such as another service (because everyone loves micro services, right?).

Side bar: is IKEA built in Rails? 😂 That would be pretty neat.

Unfortunately not, but I agree that it would be awesome. 🙂

Side bar 2: I need to go run to IKEA later... 🤔

Me too! Need to pick up GODISHUS for my oldest son. 😅

[robacarp]

My experience with building out the amber_router led me to a few lessons:

• Because every framework under the sun has different powers, anyone coming to lucky is going to have different expectations. Some people want completely arbitrary placement of variables because they come from Phoenix, some people get offended if you're not doing a full trie or radix tree or whatever algorithm because they've been conditioned to believe that's what matters.
• There are some superstitions about routes and SEO practices. Some people believe slugging IDs into URLs in their own path component creates negative SEO points (/path/:slug/:id). Other people believe that putting IDs onto a segment where the slug exists (/path/:slug_:id) degrades from the SEO benefit of that slug.
• Developers have a rather emotional attachment to URL schemes which makes it easy to step on toes. For example, I don't like underscores in my URLs. And my toe hurts! 😂

From an algorithms perspective, the simpler the better. This logic runs at the beginning of every request. It's not premature to say that some performance optimization here is important -- the amber router publishes performance comparisons for this reason.

If you're enforcing suggesting that word-case is by underscores (kabob case?!), it could be dangerous to also run the request-time path navigation operation by underscores as well. But maybe it's not -- I haven't looked at the lucky router in something like 2 years. I'd like to see the before/after matching performance on a tweak like that.

[paulcsmith]

This is really thoughtful and helpful! Thanks for sharing!

[paulcsmith]

I’d have to dive into it more but I’m not against allowing more complex routes. My main concern is performance and maintainability of the router code. We were able to add globing and optional paths without performance issues and code was fairly clean. If we can do that for this then that is fine by me

My personal opinion is that new apps can use a slash instead of a dash separator and it’d work just as well but as @robacarp mentioned this is largely preference. Also we have a anew style enforced that enforces underscores but it is optional and can be removed or replaced with your own that enforces dashes for example. Underscores we’re just the easiest to do and what I personally use hah. I’d love to have one built in for dashes though!