Closed GuillaumeCisco closed 6 years ago
theres a couple things which have changes, the docs are currently being worked on, i realized a little too late there were some additional things required
history
is no longer a peerDep and not sent to connectRoutes
const { reducer, middleware, enhancer, thunk } = connectRoutes(routesMap, {
...options,
initialEntries
})
Check out redux-first-router demo, its been updated
Thank you @ScriptedAlchemy, I succeeded to make it works with the last release of RFR. Indeed, the history was passed as the first argument. I now have a question, I have deleted all my history related js files. How does RFR deals with history?
In the past, I had a history js file for the dev/prod/electron environments as you can see here: https://github.com/GuillaumeCisco/guillaumecisco/tree/master/src/client/root/history
Thank you,
I think creating a README file on how to migrate should be great :)
So history, is now something we wrote ourselves, its actually from Rudy.
Id suggest looking at how we consume the history package. we have both a memoryHistory and browserHistory -- so in theory you should be able to route outside the browser.
RFR2 was before my time, I am spearheading Rudy's development - so some of RFR2 i am still getting up to speed on.
Before opening a new issue, I'm sorry to ask this here: is it always loading home route (/
as path) when you reload your browser from another route (eg. /:list
) with RFR ^2.0? I updated it from 0.0.20-next
and removed everything about the history
package but I don't think that it is related. I will have a deeper look next week but I tought that you may have come across that issue...
Sounds like something in the page reducer, causing it to default to home.
Ive not enchanted that issue, are you using the extra
prop or bag
props? theres been a slight update to that as well
Oh yes good catch it was server side... I simply forgot to pass initialEntries
to my initStore
function and then use it via the connectRoutes
options
parameter. It was read by connectRoutes
from the created history before. Thank you @ScriptedAlchemy.
:D no problem!!
If you can improve the docs, for others who might have these issues. Feel free to PR :)
Anything vital you had to figure out on your own, to upgrade or do something different. Just drop a comment here, or PR and ill add it. We are working on docs but any bit helps :P
Keep an eye on Rudy too. It might just be finished (finally) - Some docs and tests need updating, but thats the least work at this point 😂
I will definitily take a deeper look at the actual state of Rudy. I just quickly scanned the repo and it seems that respond-framework/rudy === redux-first-router ^2.0
and that switching to it will result in fewer dependencies, as redux-first-router-link
is also packaged in respond-framework/rudy
.
It already has been said by other people but keep up the good work! RFR, RUC, etc... doesn't have the attention they deserve in the React developers community, imho. Sadly I can't help much with that as a freelance.
On the surface, it looks like RFR 2.0.... Well thats because RFR2 is actually redux-first-router@rudy
Its an ancient version - from a year ago.
Rudy, is something was built for respond, its significantly different, more powerful - but our initial ideas can be seen in RFR2.
Rudy has goodies like caching built in, universal will be no more, even though we have it in here for the time being, I plan to use React 17 in its place, Reacts monorepo, in some way depends on RUC (at least according to github?). Anyways, I intend to use React 17 to base the new demos off, seeing as ill be able to rely on Suspense to handle async.
So what Rudy is, is a Rails-like application controller for Redux Applications, what im still hammering out, is nested routing - where like in rails, you can have additional routes added lower down in other controllers - like how you do it in React Router, nesting routing logic in child views.
The idea is, with our new createScene
functionality (Just one file of Rudy) we can initialize sub-controllers or scenes
where these viewControllers can operate. This would alleviate needing to pack everything into RoutesMap right from the start, with other work - we will have async redux reducers dynamically added along with new route controllers on the fly. Itll let you pack on and preload routing logic, views and date - dynamically.
RFR is a router, Rudy is an application controller. Rudy aligns closer with Respond than RFR. It was built for Respond, and make sense to move it to a new home, under its new name.
I released RFR2 because, RFR needed an update - i had no idea what version master was or what all the branches were for. So, I released the Rudy branch - one that i was more familiar with. The idea being, to give the users a much needed update and kick everything into a renewed support cycle for RFR, on an api that ill have a better time supporting.
The repos are also all under faceyspacey, to which i have limited access to - adding maintainers is just easier, moving forward is easier if ive got more flexibility with the repo :P
Rudy needed a home, and everything just moved in that direction
Thank you for those details. I had subscribed to https://github.com/faceyspacey/redux-first-router/issues/218 where you already have shared most of them but I did forget them in my previous comment, sorry. I'm not surprised that Suspense remove the need for RUC. All about Respond sounds very great and exciting!
Indeed :)
Respond requires remixx to be completed. I’m actually enrolling for a degree in computer science, so that I can better build it.
Rudy will be a stand-alone product, but we built it for Respond, it provides an api which Respond is to be built on
@ScriptedAlchemy When you say "universal will be no more", I'm assuming you are referring to eliminating a dependency on RUC, not that universal rendering/SSR won't be supported in the new version, right?
Hahaha!Probably the most important clarification. Universal will most definitely be supported. However I will not have to write and maintain the library is that make it possible for react to be universal. Facebook has included RUC in their monorepo, what I assume is that some of suspense was initially inspired by some of our work
Okay to close this out>?
Just updated to
Redux First Router 2.0.1
and got some weird errors. Looks like thelocation
obtained thanks tostate.location
is not the same as before. Not samestate.location.routesMap
.Before, I got the
routesMap
defined as I pass it to theconnecRoutes
method:But now, If I look into the
routesMap
of thestate.location
, I have something like:Furthermore, I use Redux First Router Link too, and I cannot now create my routes, I get an error like:
Looks like the
routesMap
is not correctly mapped. Do I have to change my initialization?Will stick with version 1.9.15 for now