-
Notifications
You must be signed in to change notification settings - Fork 140
Using redux-first-router within the application with the base URL different from '/'? #103
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
So u want all URLs to start with /basename? Correct. This is a feature I plan to add this weekend in fact. Can you do a test for me? Look at the history package; you will see they accept an argument for this. Can you verify RFR fully functions when using their 'basename' arg. |
At the client side everithing OK - |
My experiments I'm doing are on your redux-first-router-demo. I have At client side as I said above everything is OK - after At the server side (javascript app - demo app based on your The url mismatching appears when I attempt to refresh browser while current url differs from '/', for example, But there is interesting thing I've observed from time to time while I'm playing with Now I am trying to find the cause of error while using ssr. |
Can you send me a repo? |
Here it is.. But there is nothing special except for eureka connection and publicUrl/basename changes... |
You can cut eureka connection, it does not effect on something. |
So, I found the solution. It has no relation to redux-first-router - I've change settings on my cloud part and now it works perfect with redux-first-router! I enlarge ribbon and eureka timeouts and that was enough for fix this strange behavior. Thank you James for fast reaction and my best wishes! |
That's excellent. So just to confirm, basenames provided to both histories works perfectly and there are no changes RFR has to make?
I'm still gonna look at your repo later today. I need to verify absolutely every use case works. This is exciting news though. |
The comparison is here.
and this works perfect.
does the job properly whithout any changes.
5.The basename do removed in action.meta.location.pathname, indeed. Now I'm trying to call history#push directly. |
If I insert a string
Hooray! |
So basically the history package's memory history does not support the basename option and that's the problem. Compare each by searching for the word
The plan is now to fork the packages and add the feature. I'll do a PR, but i did one for something else and I dont think the response time will be as fast as we need. We're also going to import the history package manually when RFR becomes Rudy (well, in the @next branch too). So you will no longer have to provide this package, and we'll pass along all relevant options. These sort of things are ultimately what we gotta do to control our own destiny. Any help would appreciated. If you wanted to create the fork of memory history (and you probably should create a PR to That should actually 100% solve your problem if client-side is working. |
No, James! May be my english mislead you... There is no need to fork history package! Memory history, as it initialized in demo app, works perfect as is. Basename property need to be specified only in browser history. The main problem of mine was incorrect configuration of my backoffice. I increase timeouts, I edit several properties and now everything are working. As I understand, when memory history is initialized, base URL is added somewhere inside of history offal. Now all work. See the clone code of redux-first-router-demo link above. All parts, client and server side, work at the moment. |
May be, memory history works correct without |
I see. The only thing is the URLs are not in fact correctly embedded in the HTML, which isn't good for SEO. They dispatch the correct actions when clicked, the history api will push the correct URL with the basename in the browser, and in fact the markup checksums match when going from the client to server, but if you inspect the page or view the source the URLs are not correct. So search engines will pick up the incorrect URLs, even though the app knows how to handle them. I know what needs to be done. I've finally started on this now. |
Ah, I got it! This thing I didn't take into account... You know, I'm not very experienced in SEO, postponing SEO to later, but if I can help you with smth, please let me know! We all are interested in SEO to work properly. May be, I can help you with some tasks, I'll be glad to help you! You know, I'm more experienced in server-side java world, but I'm always happy to new knowledge. |
Any help is much appreciated. If you can help me clone the basename stuff into memory history, I can make the links prepend the pathname. I'm going to bed now but will pick up in the morning. |
OK. |
If my understanding of logic of the browser storage is correct,
Here is our long-suffering demo. The Notice: |
We need to pass We can get this corrected url by concatenating |
Yestarday I learned how |
You around? ...sorry, i got bogged down with client work. I'm diving into this now. |
The latest code is in the next branch: https://github.com/faceyspacey/redux-first-router/tree/next ...Also, I'm already monkey-patching the ...I'm going through all your code now. |
I understand, James, that you write this in your spare time, thank you for that! We did similar job in parallel... |
|
Trying to commit, I got test errors... I need some time for fix them. |
See my wrapper. In demo, src/index.js:
server/configureStore.js:
|
So, for user, changes are only to change history source to wrapper and add |
And, indeed I don't use first attempt to edit history package in this wrapper. It is alone, and should wrap original history package. |
Now I'm going to make full url useful. Some reading before... |
Now I think, may be user should initialize original history package themself, but pass it to our wrapper?.. With, in case of memoryHistory, an additional |
May be I'm wrong, but I cant see that changes... |
Ok, sorry about that. I got pulled away again. I'm here and have no distractions. So what I meant by monkey patching is this: I had to do it for the Now instead we are going to make the package ...So I'm going to make sure tests pass on After that I'll remove my current monkey patching technique. By the "money patching" is almost a technical term, and it means when you overwrite functions in another library. It's best to avoid doing that, especially since it can have unpredictable side-effects for advanced users using In short, u did all the primary work in your commits yesterday to fork Starting for real now. |
Ok! |
ok, the package is live with tests and one other small new feature to maintain parity to browser history: https://www.npmjs.com/package/rudy-history ...time to incorporate it in Rudy. |
i decided to PR the original history package even tho we wont be using it (at least for now). gave u credit: |
Done. It's on npm. You can get it like this:
you can use it like this: client: connectRoutes(routesMap, { basename: '/awesome' }) server: connectRoutes(routesMap, {
basename: '/awesome',
initialEntries: request.path // || [request.path], but not history
}) Notes:
Implementation details to check out: |
I'm going to bed. let me know if there are any bugs. if there are, and u pr, make sure to pr the rudy branches on this repo and the link repo. |
Great news! |
I have tryed it only today. It doesn't work properly under demo code. Now I'm looking for why. |
Check the package.json files and make sure ur in fact using th correct versions of both RFR packages. |
I clone both
Now I recheck whether I've made any mistakes in demo user code. |
I've made fixes. The problem based on absent basename striping when not action is using. |
And, if it is not already done, I'll check the new code and the fixes on demo app in both modes, with and without |
look in forward to seein it. i made tests, but i didnt apply it to a demo. |
Oh, it's ok! You did a great job! You write it in your spare time, instead of "enjoy life as it is", not only for yourself, doing it free of charge, for community. So, it is not bad that community should do a little job for themself. :) |
Well you did! You made this one super easy for me to finalize. Thank you, not me! |
You overestimate my contributions... Anyway, thank you for the warm words! Now I see test errors (router and link too), so, before commit, I should fix them. |
James, I created the pull requests, see below:
|
And, after/if you merge my pulls, we should change versions in package.json in all our depended on each other packages. |
Demo app has been updated. |
Just wanted to say thanks for this feature & discussion @faceyspacey & @re6exp - tons of good work here, and the documentation/history (ah-hyuk) to back it up. Cheers. |
How to use this component with
history/createMemoryHistory
at server side, if we have base URL different from '/'?This code doesn't work:
const history = createHistory({ initialEntries: [req.path] })
This doesn't work too:
const history = createHistory({ initialEntries: ['<publicUrl>' +req.path] })
The text was updated successfully, but these errors were encountered: