I am running into a very sporadic issue. It doesn't happen often but, in our React application, history.push(URL) does not always work as intended.
Typically, history.push will be handled by the React UI to navigate between React routes - it won't send an actual page request for whatever the URL is. 99% of the time this works perfectly fine - however, we are seeing cases in which history.push(URL) is actually sending PAGE REQUESTS to the server. This results in a 404 Not Found error.
Here is the code snippet:
this.props.history.push(`/live?watchNow=true`)
In what scenario should this actually happen?
You are changing the UI to /live route. Since React is a SPA (in case you do not use Server Side Rendering), it won't make a request for a new page to the server. But if you refresh the page with /live?watchNow=true, you browser will make a request to ressource/live?watchNow=true with parameter watchNow, nevertheless it should show up.
By the way push from useHistory do not make HTTP request (Docs), so check elsewhere.
Related
As next.js leverages server side rendering, little confused about how its improving the response time of the page navigations after the page load of the websites. This is after the first page load when user tries to access links or different routes in between.
My assumption is, when a user visits a website at first the next.js server sends the HTML build and the react renders within milliseconds, as the java script conversion is done on the server side.
Now if the user clicks on a link, when he is redirected to a different route, does the request to the server happen? How are we getting the processed javascript to the new pages/content? Again hitting the server?
Or
As the entire React code is considered as single HTML DOM, the navigation is not hitting the server again. If thats the case the server needs to render the HTML only once in the entire process.
Could some please confirm whats happening when the user tries to navigate between pages/links in a React app integrated with Next.js after the initial loading
I am using Apollo Client.
There's a route /restaurants/${restaurant_name}/places where it lists all the places for concrete restaurant_name.
Let's say I am on the /restaurans/france_res/places route. On that route, I can add new place for it. I add it and when it's done, I redirect users with history.push to the following route - /restaurans/france_res/places/place_name.
Now, if user goes to /restaurans/france_res/places route again (with no refresh, just react router's navigation), Apollo doesn't query the server any more and the places that route shows doesn't include the new one. This is because of the cache policy and it seems like the route /restaurans/france_res/places is already cached...
What could be the workaround for the following situation ?
using no-cache policy seems too harsh... Then what's the point of Apollo's caching policies in the first place ?
I don't use Redux, but I don't know how that could help me. There's a way with Redux, but it's not good.
Maybe, when new place gets added, I make user redirect to the route without history.push which will cause the hard refresh, causing queries to get executed again.
How do you handle situation like this ?
I'm working on a project and I have two components called home , about components.
When I'm on the home component and I'm going to the about component everything all right
but When I'm on the about component and Reload the page again error not found(404).
what?
The problem is, on your first load (at home component), client receive the whole ReactJS App and the routing from that point will be handled by ReactJS App (client routing). In your second case, you are at the about (component) and reload the app, the request send to the server like .../about and no route on server match it then it returns 404.
P/S: Follow along with Next official tutorial, you will face that case and they explain quite clear about it.
https://nextjs.org/learn/basics/getting-started
The issue is that I have an initial fetch request that gets the query string from the URL and makes a request to get a specified product page.
The same logic and routing is used on the client side and server side.
The API request gets executed in redux-saga, but, when it fails (no matching product), the site is already on the /product route, and so redirect needs to happen.
On the client-side this is very easy, as it can be redirected dynamically using browserHistory or just window.location.href, but on the server, i would have to pass down the res object and use res.redirect and, possibly, use two different redirect functions with this approach.
The other solution is to catch this in a topmost fashion; on express index.js during ReactDOMServer.renderToString(component), and also on the client side endpoint when it fails - with different logic. For example, a 404 view with express redirect. But, because saga is not the topmost in hierarchy anyway, throwing this 404 and catching it in the uppermost context (express server) requires passing it up and up in a very "dirty" try/catch way.
Any suggestions how to tackle that in terms of correctness? I really don't want to have routing logic doubled up on express side, so I'd rather have it handled nicely with isomorphic code.
You are probably exposing your main state to be picked up by the front-end code. Any calls that are returned from sagas can update that state. We are using a set404() and set301() actions when redux saga does not return the data we want. These actions are triggered and they set return404: true or return301: true in the main state object. So before rendering our app to string we inspect that object. If any of these are present we return a relevant response from the server.
I am building an isomorphic app with React that must support users without JS.
I am new in this technology and I have a basic doubt:
The server can store the components states to emulate what React does in the client-side?
I imagine this flow when the user dont have JS:
The user click a button and send a request to the server.
The server recovers the state of the app and makes changes in it.
The components listen this changes and are rendered again.
Is it correct?
Assuming that you're using react-router :
The server aims to initialize your state, to provide it the default minimum values necessary to make your application work while getting an url.
For example, if you have an application in which you want to display a user list, let say on /users URL, when you'll send your first request, the server will store the users in the react state.
After that first load, you'll be working on the client side using react-router, and making XHR request.
However, if you refresh your page, the process will start again : first load initializing the state and then client side navigation.
EDIT : Explanations =>
When you want to use react on the server, this means that you use a Nodejs server. The fact is that react-dom provides a method called renderToString that transform a react jsx component into standard HTML.
This aims to load the first call faster
Why ?
When you load a "big" JS application on the client, you have some delay time, the time your browser needs to download your JS bundle.
Server side rendering aims to avoid that behaviour, or at least, to gives the feeling that the app starts faster.
In no case you can only use react, even if you use your server side renders. Why ? . Because your events on buttons, or asynchronous load on client, or keypress are in JS language.