Comments (8)
Can't you just take the location from the first history.listen
callback?
from history.
history.listen is called internally in react-router.
from history.
Similarly, we have our reasons for not exposing getCurrentLocation
; it was never intended to be public API.
Instead of describing how our API should change, why don't you try describing what you're trying to do? There's probably a better way to do it.
from history.
match was never intended to be public API
This seems to imply that there is another way to do server side rendering using React-Router that allows for 302/404/500's, but match
is what the current docs state. If this is not the intended public api for server rendering that allows for redirects, that what is the appropriate api?
why don't you try describing what you're trying to do?
I'm running an Universal React app. IMHO that means the api client side and server side shouldn't be vastly different. With that being said it seems the best way to do that is to use match
client side as well as server side.
match
requires a location
object to work, while client side, Router
requires a history object. So I end up creating both a history object and a location object client side to initiate my app to preserve the symmetry that I love while building Universal JavaScript apps. While I can create both a History object and a Location object client side, it is hacky to have to create both of them separately when History can create one internally and return it to me synchronously.
from history.
Gah, sorry. I misspoke. match
is definitely public API. getCurrentLocation
isn't.
from history.
Yes, that makes sense now, but what is the issue with adding a synchronous method to retrieve the current location object? Or what would be a better solution for the use case above?
remix-run/react-router#1990 demonstrates there is a demand for a better solution to the isomorphic problem. Perhaps getting match
to pull the location object from the history object when it is not present?
// server
match({ location, routes }, (err, redirectInfo, renderedProps) => {
// send response
});
// client
// match does not find a location object but does find a history object, so it pulls
// the required location object out of that.
match({ history, routes }, (err, redirectInfo, renderedProps) => {
// send response
});
Either way there is going to be a need for a synchronous API to retrieve the location object.
from history.
I'd like to keep getCurrentLocation
private in case we need to make it async at some point in the future. Specifically, I'm thinking of React Native which doesn't have a sync method for retrieving data from persistent storage. Instead, all we have is AsyncStorage
. If we use that on React Native, then getCurrentLocation
will need to be async in some cases and sync in others. This is complexity I'd like to avoid in the public API. Instead, our public API is simply "call listen and we'll call the callback as soon as we possibly can".
I agree, however, that there is demand for a better solution to the server rendering problem. But this isn't it.
from history.
I see. I have a solution that would involve changes to match
that would make this unnecessary. Should I open an issue on react-router or maybe y'all have an idea of already in the works?
from history.
Related Issues (20)
- Named exports donβt work with Node.js ESM support HOT 1
- Sourcemaps are blank HOT 1
- Use History in redux actions HOT 2
- Location type should have template for unknown for state HOT 3
- doing history.go() does NOT trigger a blocker callback handler HOT 1
- Did TS declaration file disappear for v4? HOT 4
- Wrong action after clicking on Forward button in browser HOT 3
- Need history.BackTo(string)
- Is it possible to access the history bundled into React Router? HOT 1
- globalHistory.pushState function excuted failed in baidu.app
- [v6] Missing hashType={"noslash"} of HashRouter HOT 3
- [react-router-dom v6] HashRouter support HOT 1
- Add index property to BrowserHistory, HashHistory and corresponding Update
- Why `history.length` is gone? HOT 7
- createBrowserHistory() breaks history URL on iOS 11
- history
- is this project abandoned? HOT 2
- Navigate replace without generate new location.key
- hash history url is not parsed correctly with query params
- ReferenceError: document is not defined in Next.JS HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from history.