I am wondering how to resolve a preloading of components based on user's location. For example: he is on home page and there are 5 links to another pages (like Products listing, Login, Register etc) and I am trying to preload these pages (download from server) for best (fastest) user experience - so user doesn't have to wait for pages to download.
Let's say I have already resolved the code splitting. How would you analyze a page for Links (react-router) and preload those relevant components?
I use React 16 with Nodejs (Express)
btw. I would be very happy for typescript specific use case
Related
I'm building a react web application that has around 7 different routes. The landing page is a sign in route that has a background image it retrieves from cloud storage (according to the url params, as several different client stores will use the domain). I'm trying to choose between client-side rendering or server-side, SEO is not important for me. I would like the initial page load to be fast but also the subsequent page views, and from my reading CSR is better for subsequent pages and SSR is better for initial page loads
But I was unsure if route changes are considered subsequent page loads? Because doesn't the window tab itself not actually go through a full page reload(?) ( for example in comparison to when I enter a url in the browser and click enter) So if this is truly the case, is SSR just as good as CSR for these route changes in my app?
Also, I know initial page load is faster with SSR but I was wondering if maybe the CSR initial load page time is also good enough usually? Meaning the user experience isn't hurt
I'm learning nextjs and read in some places that nextjs only prerenders the first page and in some other places they say nextjs prerenders all pages by default so I cant understand which one is true
There are different rendering stategies. You can select which one NextJs will choose for each page by adding a method in your page file.
getStaticProps will prerender an HTML file ate the build time, you can still have a useEffect to hydrate the content of the page.
getStaticPath is kinda same but you can prerender differents pages for different routes, or on demand on non existing paths if fallback: 'blocking'is provided
You can also go form ISR (Incremental Static Regeneration), an inbetween Static/SSR, where pages are generated on the demand and cached for the amount of time specified by adding revalidate.
getServerSideProps will render the page on demand
Every one of this rendering strategies have strength and drawbacks, static pages are useful for first render but can need another round trip to hydrate content. Server render is usefull for SEO but can yield to higher server CPU usage.
What is nice is that you can choose which strategy to employ depending on the page you render.
Edit: I did not add it but the principe of these methods is that you fetch data/do stuff in them, and their return statement will be consumed by the page they live in as parameters.
i got a question about the rendering behaviour of react. Please correct me if I'm wrong, im new to React and Web Development.
Afaik the default rendering of a react SPA happens on the client side, right?
So this means the whole JSX code in the src directory will be downloaded on the first visit of the page (see image of the Chrome WebDeveloper Tools Source Tab), right?
Let's assume i would develop an admin area where only authorized users should have access to, e.g. through JWT, the JS-Code still contains information about the admin area, even if it's not rendered, a guy with the corresponding knowledge could get access to the area because all information about the admin area is already downloaded to the client computer, right?
Sure i can protect sensitive data through the api and JWT Token, but what about if i don't want the client to know about the admin area content? Is there a best practice for some kind of this case, e.g. a mix of client-side (default user content) and server-side (admin area content) rendering? What would be the best way to do this? What are the advantages and disatvantages of client-/ or server-side rendering?
Thank you &&
please be kind, as already mentioned i'm knew to React and WebDev &&
sorry for my english, i try to improve it continuously.
Afaik the default rendering of a react SPA happens on the client side, right?
Not necessarily. It depends on how you set up the project.
So this means the whole JSX code in the src directory will be downloaded on the first visit of the page
Not necessarily. e.g. see Webpack code splitting.
Sure i can protect sensitive data through the api and JWT Token, but what about if i don't want the client to know about the admin area content?
Don't put the content in the app. Keep it in the data that is protected by your JWT.
Or make your customer facing application and your admin application different apps in the first place.
What are the advantages and disatvantages of client-/ or server-side rendering?
Server-side rendering is faster on initial load, works when JS fails, and is better food for search engines.
Client-side rendering is faster on subsequent page loads.
It's not really a factor in security.
Note: I am kind of new to web development so please help me through any misconceptions I might have.
I am trying to learn the MERN stack. As an example, I am trying to make a two page site with a homepage and an about page. I made a ./public folder and added an index.html and an about.html to that folder. Then I started by learning some basic express where I have this line which will let the server serve static files from the ./public folder:
// set static folder
app.use(express.static(path.join(__dirname, 'public', )));
After I felt good about this, I wanted to add React to my existing project. This is where I ran into some confusion. It seems like React doesn't allow multiple pages in my website; I saw this SO post. So, React is good for building single page applications. I also saw this YouTube video where the first three minutes explain the difference between traditional multiple-page applications and React SPAs. He stated that all the pages will be sent at one time and the react-router will intercept any page requests and re-render the browser with the pages it already received on the first page load.
So, finally we get to my question. Going back to my example, suppose my about page is VERY large, with a lot of text and images. Isn't that potentially wasteful if I load the homepage, but the server has to send the entire website including the large about page, even though I might never even click on the about page? Once it is all loaded, I understand that the client has a smooth experience going from one page to the next without having to contact the server. But doesn't it mean that the client experiences long initial wait times. And, isn't this wasting server resources by sending pages the user might never click on. And the problem only seems to get worse the more unique pages the website has.
"He stated that all the pages will be sent at one time and the react-router will intercept any page requests and re-render the browser with the pages it already received on the first page load."
This is an oversimplification that is at the root of your misunderstanding.
Your react app is going to be a small amount of HTML that acts as the document root, and then a fair amount of CSS and JS. This JS React app will execute to generate your pages based on how you have configured your views and wired them to any data model. Generally with a SPA like this, you will load one view at a time, and it will, if applicable, make a request to the server for any data it needs to render, which will generally be returned as JSON. Once the JSON is received, it will get parsed in the browser into the data model and the UI will update to reflect the new state of the data model. Critically, each view (if wired correctly) will only fetch data from the server when the view loads; furthermore, any images or other assets in the UI will only be loaded when the UI renders them, so there will be no prefetching that wastes resources.
Because the react components can basically act as templates, you can actually save bandwidth in this way. Say you had 100 product pages on your site that were identical except for the product information. If you were to serve a new HTML document for each page there would be duplicated bandwidth in the markup sent each time. However, in React you can define a single <ProductPage /> component that will fetch only the product information and load it into the markup template each time, removing the issue of sending duplicate HTML.
There are also additional ways to split up your react app using tricks like lazy loading, to only fetch the salient JS when it is about to be used.
So, no, using a React app does not mean that it fetches all the HTML pages and assets for the site all at once. While one could write a React app in a wasteful manner, most properly structured React apps should be smaller than the rendered totality of the site.
I was creating a blog with nextjs MongoDB and express. I used getStaticProps and getStaticPaths to generate pages dynamically and display each blog on a separate page. but after deployment, if I add or remove a blog from the API then. it is not reflected on the website until the next deployment.
This is the expected behavior when using Next to build a static site. At build time, it's going to use getStaticPaths to generate a list of all the available pages for your blog, and then it will build each one into an html file using getStaticProps data. From that point forward, getStaticPaths and getStaticProps won't run again (they run in development mode, but not when you build and export your site).
So when you delete or add a blog post, the static website doesn't know anything about that because it's just a "dumb" set of html files. You have generally two options:
Set up a build pipeline that listens for changes (add, remove, update) to your blog content and rebuilds your site when the content changes, or
Switch to using Next in SSR mode instead of SSG mode, which would allow you to use getServerSideProps which runs on every page load and which would update immediately as your content changes.
That second one (using SSR) requires you to run your Next site on a node server like Vercel or Firebase Functions or something similar versus how you have it now (SSG) where it's just a bunch of html files and javascript and can be hosted in places like Github pages or Amazon S3.