Although this is more of a power user feature, I do find myself using this all the time where I implemented these kind of clean URLs. You can use the URL bar as a way of navigating:ДЇor example flights/amsterdam///2 is a pretty easy URL to grasp, it almost invites you to edit it manually instead of using that city selector or time widget to specify your search query, I think flights?from=&city=amsterdam&till=&page=2 is not all that inviting. When optimizing for a keyword audi rs7, google likes cars/audi/rs7 more than cars?brand=audi&type=rs7 (atleast this was the consensus when I was still into SEO). Inbox/1/email/desc vs inbox?page=1&order=email&order_direction=desc. Urls without using a querystring are shorter and look cleaner: They may clutter your google index pages or prevent CDN caches when these params are not always in the same order. You can have a single unique URL for each page:ДЇor example, using pokemon/fire/2 vs using a querystring, which will have multiple possible urls: pokemon?type=fire&page=2 and pokemon?page=2&type=fire. There were, and still are, reasons why people do not want to use the querystring for these kind of things, here are some advantages you get when not using the query string: htaccess rewriterule to rewrite urls like /$order/$page => to something like index.php?order=$order&page=$page, in order to get those clean urls. However, folks at reference the old PHP days quite a lot, and they might remember that before the nginxes and node servers, people used apache's. For example for ordering, filtering, pagination of the inbox you would start using the querystring: Thus, it is suggested that you use query params. When you want to use optional parameters, these are (almost) never related to the hierarchy of the page.

User -> Messages > Inbox with the route user/messages/inbox. In the context of Remix, the pathname of the URL is mainly to follow the hierarchy of your page, for example: I will give my take on this because I find it rather unfortunate that in 2021 the most popular Javascript router doesn't support a pattern I've been using successfully for almost 2 decades.ДЄs far as I can see from reactions and discussions in this and other issues, the reason optional parameters are not supported in v6 is because they don't work well with the idea of the / (in the URL) representing a step deeper into the application.

React router dom url params