faceyspacey / redux-first-router

🎖 seamless redux-first routing -- just dispatch actions
MIT License
1.56k stars 143 forks source link

RFR >=2.0.0 routesMap and RFRL #305

Closed GuillaumeCisco closed 6 years ago

GuillaumeCisco commented 6 years ago

Just updated to Redux First Router 2.0.1 and got some weird errors. Looks like the location obtained thanks to state.locationis not the same as before. Not same state.location.routesMap.

Before, I got the routesMap defined as I pass it to the connecRoutes method:

import {NOT_FOUND} from 'redux-first-router';

export default {
    HOME: {path: '/'},
    [NOT_FOUND]: {path: '/404'},
};
import {connectRoutes} from 'redux-first-router';
import routes from '../../app/routesMap';
import history from '../../app/history';

connectRoutes(history, routes, {
        initialDispatch: false, // I'm using redux-sagas
    });

But now, If I look into the routesMap of the state.location, I have something like:

{
action: "POP",
block: ƒ block(),
createHref: ƒ createHref(location),
go: ƒ go(n),
goBack: ƒ goBack(),
goForward: ƒ goForward(),
length: 29,
listen: ƒ listen(listener),
location: {pathname: "/", search: "", hash: "", state: undefined},
push: ƒ push(path, state),
replace: ƒ replace(path, state),
}

Furthermore, I use Redux First Router Link too, and I cannot now create my routes, I get an error like:

toUrl.js:35 [redux-first-router-link] could not create path from action: {type: "HOME", meta: {…}} For reference, here are your current routes: {length: 29, action: "POP", location: {…}, createHref: ƒ, push: ƒ, …}

Looks like the routesMap is not correctly mapped. Do I have to change my initialization?

Will stick with version 1.9.15 for now

ScriptedAlchemy commented 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

ScriptedAlchemy commented 6 years ago

const { reducer, middleware, enhancer, thunk } = connectRoutes(routesMap, {
    ...options,
    initialEntries
  })
ScriptedAlchemy commented 6 years ago

Check out redux-first-router demo, its been updated

GuillaumeCisco commented 6 years ago

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 :)

ScriptedAlchemy commented 6 years ago

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.

https://github.com/faceyspacey/redux-first-router/blob/5e8485369a462a1191e7ecf4b80ea110a1b76835/src/connectRoutes.js#L12

cdoublev commented 6 years ago

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...

ScriptedAlchemy commented 6 years ago

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

ScriptedAlchemy commented 6 years ago

Read over here

https://github.com/faceyspacey/redux-first-router/pull/306#pullrequestreview-164234340

cdoublev commented 6 years ago

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.

ScriptedAlchemy commented 6 years ago

: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 😂

https://github.com/respond-framework/rudy

cdoublev commented 6 years ago

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.

ScriptedAlchemy commented 6 years ago

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

cdoublev commented 6 years ago

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!

ScriptedAlchemy commented 6 years ago

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

dlong500 commented 6 years ago

@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?

ScriptedAlchemy commented 6 years ago

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

ScriptedAlchemy commented 6 years ago

Okay to close this out>?