I'm fetching data from a GraphQL API for each page in a Sapper app. I could request all the API content for the different pages in the _layout's preload function, I know that. The API is probably fast enough for it not too be an issue.
But... I'd prefer to just get the content for the current page. It just feels right. But I only want to get it once for each page. What's the best way to do that? If I run the preload on every route, it requests the content again if a user revisits the same page. Which is silly. Within the preload function, you can add the data to a store but you can't read the store in the preload function, so have no way to test whether it's been populated or not.
Related
My issue: For my thesis I am creating an auction site. I have an admin panel in which I would like to have some configurations so that an admin can specify that if there are 10 days before the end of an auction some components should be displayed in different ways, some should be not visible at all etc. That’s what I call dynamic presentation.
My question: Right now I am working on architecture and wondering if SSR can be helpful in any way? I am already aware that it can shorten download time of some collections from my database even by half, but I am wondering if there is any way how it can be helpful with dynamic presentation itself?
What I already know: I have read all about advantages and disadvantages of ssr or universal rendering in react. Now I am only wondering if it can be in any way helpful with dynamic presentation or it won't matter if I choose SSR or CSR.
Small side question: I don’t have the whole architecture ready yet. What I know is that I would like to have a database, one separate app for an admin, backend and frontend (either ssr or csr). My first thought on how to manage this dynamic presentation was to store some rules in the database. Then the rules could be configured in admin app should an admin want to change anything. The rules should be send to backend and calculated with some additional data from frontend. Then backend could send some flag to frontend indicating which components to display etc. In theory I could move calculating to e.g. NodeJs server should I go with SSR. What I'm wondering about is; can you think of any better way to handle dynamic presentation? What I am most afraid of is numerous ifs in the fronetend. I would like to have some more elegant solution but I have no other idea so far. For some time I thought about a scoring system but I believe it would be too complicated (instead of sending a flag, send a score and frontend will display correct things based on the score). Also it wouldn’t solve the issue of ifs on the frontend.
I am aware that on StackOverflow questions which can be answered rather than discussed are preferred but I am really stuck and would appreciate help.
Basically SSR can provide some speed on your page because all of your data will not be trying to be fetched when the react script will end with an API call. Data are fetched from database when page is requested and be passed to the component to render with the script.
Also another very basic advantage and the reason why everyone are going the SSR way is SEO. You cannot achieve SEO page with react CSR. This is because google bot etc will try and crawl your page without even render it. Is like trying to "view source" of a page. When you are in CSR the page has no content only the initial react divs empty. You need SSR to have data on the first request of the user.
SSR brings the data on the first request of the user until a reload. In the meantime react router fetches data from the api.
Let me know if that help you.
PS: also a helpful link https://medium.com/walmartlabs/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8
So, I have been searching everywhere and can't find any hints on this.
I have a REST API built with express that will be consumed by a website and in the future a mobile app.
I have to build the website and want to use react/redux, and I'm struggling to understand how to avoid the initial state to be render from server because I will have nested components and a lot of async data, and it will become a mess to maintain code both client- and server-side. Is there any solution/alternative for this?
Thanks in advance.
You don't necessarily need server-side rendering to solve this problem. You can make your components load with a blank state and then immediately fetch your data.
According to the React docs, your ajax requests should be made in the componentDidMount() lifecycle method, which fires once as soon as your initial render is complete.
If you want to ... send AJAX requests, perform those
operations in this method.
For example, you don't load your app if a user isn't authenticated, or you put up loading spinners to indicate that data is being fetched.
From what I understand, to use the browserHistory object in React Router properly, we need to use a wildcard * route so that the user is returned the single page application upon every refresh. Where this becomes a problem is when my client-side URL is the same as one of my api URLs.
For example, say I have a website called example.com and that one of the pages on this site is example.com/profile. If I refresh, the expected behavior is that it will simply reload the website example.com and route correctly to /profile, since the wildcard route should have returned the client the single page application. Where this doesn't work is if I have an API route /profile, i.e. example.com/profile. Now when the user refreshes the page, instead of being returned the the profile page, they are instead returned a JSON response from my API.
Depending on the order in which the wildcard route is declared, I can either have the API response returned on refresh, or the single page app on refresh, but not both when the API url is the same as the client side browser url.
Are there any suggestions around this issue? My current solution is to migrate all of my API routes to have /api/ prepended to them.
You need to make sure your client routes do not collide with your API routes, and prefixing API routes with /api is a pretty standard way to handle this.
There's no real way "around" the issue other than making sure they don't collide – various workarounds might be possible, but it's going to be more clear for everyone involved if routes are unambiguous.
I have recently started learning React and am trying to make a simple blogging app. I store the data (post content, comments etc.) in MongoDB and would like to render the content according to the route, such as, when I have a certain URL (like /blog/:username), I'd pull data from the database and then render a view with the data content.
Using Express, I am now using static html files ( express.static) as the view, yet this makes it impossible to render the content according to the requested route, such as:
/blog/:username/:article
It is possible with a template engine, like Jade, but Jade, as far as I know, does not work with React.
What is the correct way to make dynamic views using React while preserving the URL route structure?
Thank you
Generally speaking, there are several ways to achieve your goal. I'll sketch the one that I feel is the most natural approach when using React:
Create your blogging app with React
Use a frontend routing mechanism such as react-router to make React aware of the URL
Either fetch the data for each blog entry from the backend via an Ajax call each time the user hits a URL, or store the blog entry data in the frontend (e.g. using something like redux) and reuse it when required.
Does this make sense? If not, please keep asking...
I am running an express app and in a section I need to pass the page I'm serving some data. I am sending the file with the res.sendFile() function. I would prefer it to be in the form of query parameters, so that the page being sent is able to read them easily.
I am unable to run any templating tool or set cookies since the files are part of a cdn uploaded by users, so the information has to be contained so that it is not easily read by other files also served from my server.
Query parameters can only be sent by doing a redirect where your server returns a 3xx status (probably 302) which redirects the browser to a different URL with the query parameters set. This is not particularly efficient because it requires an extra request from the server. See res.redirect() for more info.
A more common way to give data to a browser is to set a few Javascript variables in the web page and the client Javascript can then just read those variables directly. You would have to switch from res.sendFile() to something that can modify specific parts of the web page before sending it - probably one of the many template engines available for Express (jade, handlebars, etc...).
You could also send data by returning a cookie with the response, though a cookie is not really the ideal mechanism for variables just for one particular instance of one particular page.