Where to find details about Phoenix router glob-like matching

Hi everybody,
I just saw in the router doc page the following:

Routes can also match glob-like patterns, routing any path with a common base to the same controller. For example:

get "/dynamic*anything", DynamicController, :show

Phoenix’s router is extremely efficient, as it relies on Elixir pattern matching for matching routes and serving requests.

I wanted to know what are the glob-like patterns that are actually implemented in the router.

For example, in this example does the route will match everything that start with dynamic and end with anything (with or without any number of characters between)?

I’m not sure if globbing commands are universal, but for example ? in bash mean any single character. And ** match anything recursively when related to directories.

Regarding this, will ** work in routes so that for example /**/nested can match /nested, /abc/nested or /abc/def/nested.

In general, is there a place where “glob-like” pattern implementation in routes is documented?

I’m also interested to look at the code, if someone can provide where in the codebase this part is written.

Thank you very much.

2 Likes

Elixir pattern matches on binaries can only match from the beginning. So /dynamic*anything means everything starting with /dynamic will be matched no matter what follows. The anything afterwards is the name for the param, which should hold the matched rest of the url.

You can imagine it like <<"/dynamic", anything::binary>> = path. There are no ways to be more expressive than that with elixir pattern matching, which are useful in url matching, like e.g. various globing implementations or regex can be.

4 Likes

Thanks for the reply.

So if I have the following url /something/deep/nested/ what will be the content of anything? will it be ["deep", "nested"] or simply "/deep/nested".
And what about /dynamicnested? will it be "nested" or "dynamicnested"?

As you explained it, it doesn’t really sound as “globbing” but only limited wildcard behavior, or do I miss something important?

1 Like

It seems like the docs were already updated on master, so you can see a bit more detailed explanation here:

In the end you’re right. I’d prefer naming in catch-all instead of a confusing glob-like.

4 Likes

Thanks for the link!
Indeed, it’s way more clear here.

But having the parameter name after the asterisk * is very confusing while we’re using the semicolon : everywhere else. But I guess that the asterisk better conveys the notion of wildcarding

Do you know when docs from master is being published on the official documentation webpages on hex.pm?

With the next release that includes those changes.

1 Like