Optional path parameters?

[pelotom]

In redux-little-router one can specify optional parameters in route paths, e.g. /some/path/(:foo), and then both /some/path and /some/path/hello would map to the same route, in the former case passing { foo: undefined } as the parameters. Is there a similar mechanism in redux-first-router whereby those could both map to the same action but with an optional field in the payload?

[faceyspacey]

Yea, I'm gonna optimize support for various regex-like stuff you can do. Some stuff works now, it's just "undefined behavior." What you have likely won't match, but you should be able to extract unnamed parameters (*) into payload['0'] for example.

Experiment and let me know what you find. I want to revisit this asap.

[gouegd]

I've been thinking about this one.
Adding several paths for the same route is not currently possible because of how JS works.

// no good
{
  PROFILES: '/profiles/:id/:section',
  PROFILES: '/profiles/:id',
  PROFILES: '/profiles'
}

Following another issue (#94) I'm thinking about supporting arrays of paths (or arrays of objects) for each route, like this:

/// with array support
{
  PROFILES: ['/profiles/:id/:section', '/profiles/:id', '/profiles']
}

An array support would be helpful for other use cases too (see other issue for instance), and it should be simple to get from optional path params like /profiles/(:id)/(:section) to the array above.
So, users would input optional params and we could turn it into an array of paths. Optionally the users can also just input a array of paths directly.

What do you guys think ?

Currently for optional path params I'm duplicating entries in the routeMap, so I need to resort to some tricks to avoid having super-repetitive condition checks everywhere.

[faceyspacey]

Optional params is on the roadmap. Feel free to implement it if you need it sooner.

That said the only time this is really needed is when the paths are user generated like file and folders on GitHub. So imagine one optional param that can represent any number of path segments and will give you its string in a param. Ie this /(*).

I bring that example because that is something we CANNOT currently accomplish via other ways. However it is a rare need.

As for more basic optional params mentioned here, I personally prefer lots of types in my reducers rather than having a single type and comparing payload params. It's just so easy to flatly switch over types. I don't care about the repetition.

FYI all we are solving by consolidating the PROFILES into one route is less cases to switch over in reducers. And perhaps not having to assign the same thunk 3 times. Component code shouldn't have any repetition since u write a reducer once that derives reusable state into a clean single variable you can connect to your components.

So my opinion is that reducer action type repetition is a good thing.

In the future u may appreciate the difference, and revert to breaking it back up to 3 routes. At which point it's a feature. As apps grow and become more custom, u will inevitably add more features to differentiate between the 3 routes.

So basically we are taking about a convenient option here for people that unnecessarily cringe at too many cases in their reducer. A feel nice thing, especially in the beginning stages of your app where u have high hopes for DRY and no repetition lol. I make that sound bad but ultimately it's a fine use case since accessibility is key to marketing this package and that's a common instinct to have. That's why we will support optional params. I'm not sure about the manually provided array, but I'm not staunchly opposed. At the end of the day, this would be a great first PR. Reg-to-exp already works with optional params. I just don't do anything with them. U should take a look into the pathToAction.js and actionToPath.js files.

[silouanwright]

I had to think about what you just said @faceyspacey because I didn't get it. I think I sort of get it now and wanted to flesh it out for everyone, hopefully I get this right.

The key here is the page.js component.

So here you have your page.js component which you use in your root react component to show different components based on the route (this essentially replaces the <Route /> stuff):

// reducers -> page.js
const components = {
    HOME: 'Home',
    PRODUCTS: 'Products',
    [NOT_FOUND]: 'NotFound',
};

export default (state = 'HOME', action = {}) =>
    components[action.type] || state;

So what he's basically getting at with the multiple types stuff is this:

// routesMap.js

    PRODUCTS: {
        path: '/products/:productID/',
        thunk: (dispatch => {
            // async code here
        }),
    },
    PRODUCTS_WITH_AFFILIATE: {
        path: '/products/:productID/:affiliateID',
        thunk: (dispatch => {
            // async code here
        }),
    },

The key here, is the page.js component. All you need to do is update it with your new type:

// reducers -> page.js
const components = {
    HOME: 'Home',
    PRODUCTS: 'Products',
    PRODUCTS_WITH_AFFILIATE: 'Products',
    [NOT_FOUND]: 'NotFound',
};

export default (state = 'HOME', action = {}) =>
    components[action.type] || state;

Notice how they both point to "Products". Now you just use page.js as your source of truth.

That's the beauty of the page.js component. You have types mapped to routes, but you have multiple types mapped to pages inside this page.js reducer. So you use this page reducer in this way:

function App({ page }) {
    const pages = {
       Products: <Products />,
    };

    return (
        <div>
            {pages[page]}
        </div>
     )
}

function mapStateToProps(state) {
    return {
        page: state.page,
    };
}

And you're done. Ideally you use whatever difference in the payload inside the components dynamically, e.g.

<div>
{props.products.affiliate && (
   <h1>Our affiliate is {props.products.affiliate}</h1>
)}

Or maybe faceyspacey is suggesting this?

{props.types.PRODUCT_AFFILIATE && (
   <h1>Our affiliate is {props.products.affiliate}</h1>
)}
</div>

I'm actually not totally against it... I'll need to use it and see what type of ramifications this has. The main thing here is if I consider PRODUCT & PRODUCT_AFFILIATE the same page, I literally cannot use types in conditionals... I MUST defer to page.js (unless I feel like doing `if PRODUCT && PRODUCT_AFFILIATE && PRODUCT_SOMETHING_ELSE every time I want to target a page, which I'm just not going to do). Does that increase complexity? When I'm looking at types inside the redux console, would I rather see one consistent type per route, or multiple types based on the kind of route.. I can't really tell.

That being said, I'm wiring it up right now and if it feels decent, it's going into production.

[pelotom]

It's certainly doable by having a different action type per permutation of absent vs. present parameters, but it feels not as nice to use as it could be.

[silouanwright]

@pelotom I think what you're referring to is how this violates DRY but as far as I know, @faceyspacey isn't really staunch on the DRY stuff. Maybe the flexibility and having more types makes customization and handling conditional state showing easier in the long run? I think that's the big question here... are we nitpicking over what will amount to not the greatest amount of duplication... maybe having more types speaks better to the state our program is in, rather than having to go to the component and having to see which pieces of data are specifically rendering these views (we also don't have any named associations to these different views). It's not like we're discard the extra data at the end of the path... it's most likely going to be used somehow. That being said, I'm playing devils advocate here. The approach is starting to make sense but I'd need to defer to people who try both approaches in larger applications and then make my opinion from there.

[pelotom]

@reywright what I'm advocating doesn't prohibit using as many action types as you like, so it's no less flexible. It just allows avoiding a combinatorial explosion of different action types in certain cases. For example, if what you have is conceptually MY_SCREEN: 'foo/(:foo)/bar/(:bar)/baz/(:baz)', do you want to have to write these routes?

MY_SCREEN__FOO_BAR_BAZ: 'foo/:foo/bar/:bar/baz/:baz',
MY_SCREEN__FOO_BAR_NOBAZ: 'foo/:foo/bar/:bar/baz',
MY_SCREEN__FOO_NOBAR_BAZ: 'foo/:foo/bar/baz/:baz',
MY_SCREEN__FOO_NOBAR_NOBAZ: 'foo/:foo/bar/baz',
MY_SCREEN__NOFOO_BAR_BAZ: 'foo/bar/:bar/baz/:baz',
MY_SCREEN__NOFOO_BAR_NOBAZ: 'foo/bar/:bar/baz',
MY_SCREEN__NOFOO_NOBAR_BAZ: 'foo/bar/baz/:baz',
MY_SCREEN__NOFOO_NOBAR_NOBAZ: 'foo/bar/baz',

and then elsewhere all the corresponding component maps needed to consolidate them?

[faceyspacey]

we are gonna have this fellas. it does make sense as a user's decision. and keep in mind, i'm not personally that amped about it. so that just means it makes sense, and we gotta have it.

help on code appreciated.

[gouegd]

At the end of the day, this would be a great first PR

@faceyspacey Do you refer to providing arrays of paths, optional params, or both ?

I appreciate your point about repetition in reducers not being a bad solution.
I'm also finding myself repeating this kind of branches when creating an action (pointing to different types whether there's a payload or not, which depends on the current location). I use custom actions to have a better dev experience on this.

Also as a side note I've not actually been using reducers so far, instead relying entirely on custom information passed in the routeMap per route. This is an alternative that works, but that ends up creating lots of repetitions compared to reducers, in certain cases. So I'm now moving to using reducers more.

[faceyspacey]

Optional params. Keep the API surface smaller.

[faceyspacey]

Ok, this is done. All matching capabilities of the path-to-regexp package we use are now supported, except unnamed parameters.

Let's go through what we now support. Usually it's best to start with the simplest example, but I think most people looking at this get this stuff. We'll start with one of the more complicated use cases just to see how far we can take this:

Multi Segment Parameters

So for example, imagine you're github.com and you're now using Redux-First Router :), and you need to match all the potential dynamic paths for files in repos, here's how you do it:

const routesMap = {
   REPO: '/:user/:repo/block/:branch/:filePath+'
}

So that will match:

• https://github.com/faceyspacey/redux-first-router/blob/master/src/connectRoutes.js
• https://github.com/faceyspacey/redux-first-router/blob/master/src/pure-utils/pathToAction.js
• etc

but not:

• https://github.com/faceyspacey/redux-first-router/blob/master

And if you visit that URL, you will see it in fact doesn't exist. If it did, you would use an asterisk (for 0 or more matches as in regexes) like so:

const routesMap = {
   REPO: '/:user/:repo/block/:branch/:filePath*'
}

So the above 2 options will match a varying number of path segments. Here's what a corresponding action might look like:

const action = {
   type: 'REPO',
   payload: {
       user: 'faceyspacey',
       repo: 'redux-first-router',
       branch: 'master',
       filePath: 'src/pure-utils/pathToAction.js'
   }
}

Pretty cool, eh!

The inspiration actually came from a PR I did to CodeSandBox. I didn't actually implement this there, but I was thinking about it around that time. I.e. that CodeSandBox should have the full file paths in the URLs like github. Currently it's as a URL-encoded query param, but in the future (perhaps with RFR), they'll be able to do what Github does as well.

Optional Single Segment Parameters

However, you usually just want to add optional single segment params like this:

const routesMap = {
   ISSUES: '/:user/:repo/issues/:id?'
}

So with that you can visit both:

• https://github.com/faceyspacey/redux-first-router/issues
• https://github.com/faceyspacey/redux-first-router/issues/83

Here's the 2 actions that would match that respectively:

• const action = { type: 'ISSUES' }
• const action = { type: 'ISSUES', payload: { id: 83} }

And that's basically the "80% use-case" most powerful feature here. I.e. when you want to use the same type for a few similar URLs, while getting an optional parameter.

note: you can also have optional params in the middle, eg: /foo/:optional?/bar/:anotherOptional? So all 3 of /foo/bla/bar/baz and /foo/bar/baz and /foo/bar will match :)

Optional Static Segments ("aliases")

The absolute most common (and simpler) use case for such a thing is when you want /items and /items/list to have the same type (because they are aliases of each other ). You accomplish it slightly differently:

const routesMap = {
  HOME: '/home/(list)?',
}

or

const routesMap = {
  HOME: '/home/(list)*',
}

Both are the same. It would be nice if you didn't have to wrap list in parentheses, but you have to. That's fine. Keep in mind this isn't a parameter; the 2nd path segment has to be list or not be there.

Also, the common convention we should use is the the question mark ? instead of the asterisk *. We should reserve the asterisk for where it has unique capabilities, specifically the ability to match a varying number of path segments (along with +) as in the initial examples with the github file paths.

Regexes

Another thing to note about the last one is that (list) is in fact a regex. So you can use regexes to further refine what paths match. You can do so with parameter segments as well:

const routesMap = {
  HOME: '/posts/:id(\\d+)',
}

So essentially you follow a dynamic segment with a regex in parentheses and the param will have to match the regex. So this would match:

• /posts/123
  but this wouldn't:
• /posts/foo-bar

Multiple Multi Segment Parameters

Last use case: say you want to have multiple params with a varying number of segments. Here's how you do it:

const routesMap = {
  HOME: '/home/:segments1+/bla/:segments2+',
}

So a url like /home/foo/bar/bla/baz/bat/cat will result in an action like this:

const action = {
   type: 'HOME',
   payload: {
       segments1: 'foo/bar',
       segments2: 'baz/bat/cat'
   }
}

So yes, you can have multiple "multi segments parameters".

One thing to note is you could also accomplish this like this: HOME: '/home/:segments1(.*)/bla/:segments2(.*)'.

---

Final reminder: if you do plan to use multi segment parameters, they have to be named. This won't work:
/home/(.*)/bla/(.*).

Well, the truth is it will, and given the previous URL you will have a payload of:

const action = {
   type: 'HOME',
   payload: {
       0: 'foo/bar',
       1: 'baz/bat/cat'
   }
}

But consider that "undefined" functionality. Don't rely on that. Name your segments! Like any other key in your payload. That's the goal here. Originally I had the idea of making an array at payload.segments, but then I realized it was possible to name them. So naming all params is the RFR way.

---

Lastly, to get this do:

yarn upgrade redux-first-router@next

[pelotom]

Looks awesome, can't wait to try it!

[gouegd]

Great samples, glad you already found some time for this !