Specifying a basename when app isn't hosted at site root

[corydeppen]

I'm trying to use redux-first-router in a create-react-app app that specifies a homepage in package.json since the app won't be hosted at the root of the site. From what I can tell, it looks like I'll have to include that route prefix for each entry in my routesMap. I've been looking through the RFR source to see if there's a way to pass a basename (or similar) option that would allow the pathname to be enhanced if that option exists but it doesn't look like it's possible at the moment.

Is there currently a way to use RFR when an app isn't going to run at the root of a site? If not, is it reasonable to request the ability to specify a basename - perhaps in the options passed to connectRoutes?

[faceyspacey]

Definitely a good option to have. May not come this week tho.

[faceyspacey]

I'm gonna close this because I know I won't be able to get to it until there is more demand, but a PR would be accepted.

[gouegd]

Hi ! I'd like this too.
basename is already an option in the history package. I think it would make sense that we retrieve the basename from that package and, if it exists, handle it in redux-first-router (without the need for an extra argument).
As far as I could see by scanning through the history repo, it's not currently possible, but they could welcome a simple PR. Then another one would fix this on this project.
Any opinions ? Let me know if that sounds like the wrong path. Thanks ! :)

[faceyspacey]

It's the ideal path. It would be nice to be able to extract all options from that package, i.e. via a method like:

history.getOptions()

I tell you what--you get that merged over there and I'll make the updates over here.

[gouegd]

OK, I checked more into it, and whether this already exists or not.
RR4's Links shows that they rely on history to create the proper URLs rather than create themselves. history then deals with the presence of a basename itself.
Here's where they do it

The relevant function is history's createHref, here

If we use this for RFR's Links and Navlinks, the href will then be correct. As far as I see this is all that we need - maybe I'm missing something, but at least that seems to be the first step.

[faceyspacey]

yea, that's one step. we also need to normalize the URLs throughout RFR, not just the link package.

We already have a function used hopefully in all places for generating the path + query string:

https://github.com/faceyspacey/redux-first-router/blob/master/src/pure-utils/pathnamePlusSearch.js

It's used exclusively in the main connectRoutes.js file:

https://github.com/faceyspacey/redux-first-router/blob/b86003321f7b01a2360a5a802125b9ee978a606f/src/connectRoutes.js

If you search it's usages you should be able to get an idea if we're covered everywhere. We'll also have to change history.pushand history.replace in a few places that don't use pathnamePlusSearch because the user provides the values.

The bottom line is we need to compare paths throughout, and we should do so based on the normalized version, but by the time we push new URLs on the address bar, they need to include the basename.

This is a good initial PR fyi. It's not the most complex, yet requires you to touch many places in the code-base (a good way to get familiar with the code) and make sure things are done precisely.

[gouegd]

by the time we push new URLs on the address bar, they need to include the basename

Actually, I don't think they do: history will add the basename for us.
I've checked it in an app that has a basename. Everything works. The only gotcha is that all those SEO-friendly links appear to point to /some/path (when you hover them), but when you click them, they work fine and I just end up in /basename/some/path.

Sure, the location.pathname does not include basename, but I think it may be better that way. It's a relative path: relative to where my app lives, and that's probably all that matters.

At this point I think we just need to get a hold of history in the Link/NavLink. We already access the location there, but unfortunately, the location.history key exists, but is undefined. Was that supposed to hold the history library, or some other metadata ?

[faceyspacey]

Rather, we now gotta remove them

[faceyspacey]

It holds history entries on React Native or when memory history is used.

It won't be about changing the link package. At least not first. It's about changing the core. I'm surprised this worked at all. Either way, dig in RFR core. Ur gonna have to append the base name anywhere paths are generated. I don't see how we can get around that. And perhaps it's worse in fact if some places we do and some places we dont, as that leads to a more confusing implementation.

pure-utils/actionToPath.js and pathToAction.js and pathnamePlusSearch.js are probably the files of interest to you.

[gouegd]

Rather, we now gotta remove them

What do you want to remove ?

I'm surprised this worked at all

As I wrote above, this is because the history package just handles the basename itself.
Why not let it be this way ?

[faceyspacey]

that's fine. But there may be more, and we need to insure RFR internals are updated so it doesn't break down in any scenario.

You seem to be poised to completely solve this. Why not make a PR?

[gouegd]

I always look at understanding issues before working on them :)
What more could there be ? All history changes are done through history, so I don't see why we'd want to replicate history's behaviour here.

[faceyspacey]

We don't. That's not what Im saying. I'm saying there's likely more that also needs to be done and we should find it, or this would be closed.

Just take it over brotha and take it all the way.

[faceyspacey]

basenames are supported now:

#103 (comment)