Alongside with that I of course have generic routes like ‘admin’, ‘signup’ and so on.
But when I go to /signup, the postList route gets activated, treating ‘signup’ word as a city id, and ‘signup’ is logged in console.
Defining route like FlowRouter.route("/postList/:cityId") is not an option.
I get that there is a cool feeling in having a URL just being someone’s username…if that is the main requirement, then use top-level domains for users, and move views of other context somewhere else…for example, here is twitter’s URL for moments/notifications/etc:
I don’t know how well this translates into the FR api… That’s a question for @arunoda. My sneaking suspicion is that you’d have to write something that wraps around FR’s resolver and then translates those into the more traditional FR routes. My post here is a little outside of the scope you seem to describe, but should give you (and others) a good idea of where to go from here.
A few extra pointers… if you’re looking up users or blog posts, you’re going to have to do a DB query which does cost something.
extract as much information, make the best guess as to what kinda url it is before you query
as I mentioned earlie, if you’re looking up slugs, do a regex for -'s
consider doing something like mysite.com/@rozzzly, medium.com does this, I think its pretty rad. In this case you would check for the first char being a @
another option is mysite.com/u/rozzzly
what about strings after the unknown? e.g. mysite.com/rozzzly/profile you can infer from there being a /profile that the first param is probably a username
Cache. cache that caching cache. Trying creating an map from incoming urls to fully qualified routes, this can save you a TON of processing power.
Agreed, different companies obviously have different “requirements”. What I’m asking is why is a top-level route a requirement?
Can we agree that they are more confusing to the user looking at them?
Can we agree that they are obviously harder to implement? (at least with Meteor?)
Can we agree that, unless there is truly a requirement for such, there is a better solution (as I have presented above)?
In the Github example, I think it makes my point clear. When I click on github.com/pulls, I don’t know if that page is taking me to a page that lists ALL pulls occuring on github, or just pulls for me.
In fact, that page is actually just querying ALL of the pull requests occuring on Github…your username is just added afterwards to the filter bar…remove it and…
Voila, you see every single pull request. There is no server-side filtering happening due to the URL. They are probably just checking if a user is signed in, and just adding the filter client-side if so.
I still struggle to find the problem here. Maybe I missed something.
@rhywden as OP goes with many routes, his application has at least middle-level complexity, so he should be using package-oriented architecture for that. With package-oriented architecture, the order of files is never a problem, because you specify it explicitly.
@avalanche1 inside of a file (or in multiple files in package-oriented architecture), first route to be defined gets checked in the first order. So if you specify all your /myAwesomeRoute before /:myAwesomeParameter, you achieve exactly what you wanted.
I guarantee it works because I use that in my project.
Just curious, so what happens when someone wants to sign up with the username “settings” or “new”, or another route you already have defined? Will you continue to update your prohibited username/post-title/whatever list as you add more routes to your app, and just throw the error? I’m honestly asking as I’m trying to work out all the edge-cases here.
I keep one, common list of prohibited strings that I check against each new title/name for multiple collections. So even when I want to change my routes structure for an already working application, I can still afford it, because the list will still be valid and titles/names will still be available. The list is longer and contains synonyms and alternative route names that I was thinking about to use now or in the future.
By any mean this list covers 100% cases, but gives me enough of a confidence.