chore: allow empty str

[fundon]

#19

@adriangb try this branch

[adriangb]

cc #26

[fundon]

@adriangb In this case:

Router(
  {
    "/users": Router(
      {
        "": users_endpoint,
        "/:name": user_endpoint,
       }
    )
)

Can the sub-router get the prefix path /users?

[adriangb]

Not easily. That same instance could be used somewhere else as well.

[adriangb]

I'm realizing I may have misunderstood. Just to clarify, I don't think the nested router should know/need to know that it is mounted under the prefix "/users".

With the example you gave I think the routing should be as follows:

/users -> Some(users_endpoint)
/users/ -> None
/users/abc123 -> Some(user_endpoint)

[fundon]

In writing, empty string can be used, but a full path can be assembled at the end.

Pseudo codes:

sub_router.path = ''
sub_router.routes = ['', '/:name']

parent_router.path = '/users'
parent_router.mount(sub_router)

fn mount(sub_router) {
   for route in sub_router.routes {
       let path = parent_router.path + route
       tree.insert(path)
   }
}

[adriangb]

Yeah that’s one way to do it. It’s nice to be able to support the version where the parent router doesn’t need to introspect into itself children

[adriangb]

This is a bit confusing. The path goes in as "/" but comes out as "/"?

[fundon]

tree.insert("", 14) allow change the start node value , but it does not modify the node prefix path.

1. tree.insert("", 14) node path = ''
2. tree.insert("/", 15) node path = '/', overwrite the empty string

[fundon]

Or do not allow empty string, users handle their own paths

[fundon]

here is another way to allow '' to be the root node of the tree and '/' to be its child node. (@adriangb This should be what you expect).

[adriangb]

Yea I would expect “/“ to be a child of ””

[fundon]

Because, I always consider that the real request path does not appear '', when organizing the routing system, it has to pre-process path at the users

[adriangb]

For what it's worth I was easily able to work around this one level of abstraction up: adriangb/routrie@70fc7c5

I think the fact that this can be solved one level of abstraction up indicates that the limitation is artificial/due to the implementation, not a conceptual one.