Why would someone doing SSR with Next.js use Express (or other server) instead of building and initializing with the built in next start?
The Next.js team is always working on ways to eliminate the need to use a custom server.
For example: in the past, it was required for:
static asset routing (such as robots.txt)
internationalization middleware
relay modern server
dynamic routing
Now it's just sometimes needed for middleware. Just note you could be in an old project that made that decision based on a historical need, not necessarily one that's present anymore.
Zeit themselves advertise multiple custom server examples (just search for "express").
Related
I have external api hosted in the cloud and I would like to write desktop app for management. Last version of electronjs I worked with was version 8 and over that time a lot of changed especially from security perspective. The concept of preload was introduced and I would like to know is it fine to write renderer as react app with redux toolkit and make api calls that way or should I use preload script to get data on the server side.
I would like to know what is a proper way of writing such app.
Yes, it is totally fine to use react and redux toolkit in your renderer.
To quickly get started, you could use something like electron react boilerplate or one of the several other boilerplates available online.
I don't understand why you would want to use preload to fetch from the server.
You can treat the renderer as just another browser instance and make requests to the server directly from your react app using fetch or xhr.
Preload is generally used to run code before the renderer has loaded. I generally use it as a bypass to turning on nodejsintegrations for my electron apps, but you can read more about it in the official docs
I have a huge project using asp.net and jquery. I want to start migrating to react page by page (it might take a lot of time).
I would like to know what is the best practice to do it.
Can I move pages to react partially (for example half of page), and is it good approach?
Lets say I have main page A with with links to page B and C. Can I move page B and C to react, using routing, without moving page A right now?
I think I will use Vite to create and manager react project. In the production vite generates static files so I will simply host new files next to old ones in my backend server.
The problem is with development, because in this mode vite creates new server with functions like hotreload and in the result I have two diffrent servers hosting frontend asp.net and vite.
I would prefer to have just one server also for development. Is it possible to build development version with vite and copy it to server the same way like in production? Is this good approach?
I know that it would be the best to have backend and frontend server separated, but project is so huge that it is not possible in the foreseeable future
Are there any examples out there of injecting new ReactJS components at Runtime, e.g:
A build is deployed on production is stable and running.
We need to add a component or a new route without running through an entire deploy process.
An additional usecase : the application ships with all the components ( e.g: A CMS Module library) - Only certain components were enabled in layout at build time but need more to be added later via a config.
Approaches I have considered.
Using next getStaticPaths and then using a override in the front-end to inject client side components. This will most probably be seen at runtim
Use a more faster deploy system - This is more obvious but imagine lots of changes within a day and multiple deploys.
Any similar problems or approaches people would have tried would be great.
Update Nov 2022
If you are searching on the internet and this comes up, Zack Jackson's Module Federation supposedly achieves this and is called live code sharing via Module federation - https://module-federation.github.io/ There is a NextJS Paid plugin https://app.privjs.com/buy/packageDetail?pkg=#module-federation/nextjs-mf (supports only CSR currently)
I think you would lose out on a lot of built-in build optimizations from Next by trying to circumvent the standard build process, e.g. automatic code-splitting as described here.
However, you might find the fallback feature solves your problem entirely - the fallback feature was meant for large ecommerce sites like it sounds like you're working with. As stated at the fallback true docs:
useful if your app has a very large number of static pages that depend on data (think: a very large e-commerce site). You want to pre-render all product pages, but then your builds would take forever.
I am using React in my project and I have problem with client-side prerendering.
More specifically, it would be necessary to configure SEO
Which is the least painless way to prerender existing reactjs app wiht react-routes
Some examples I have researched:
Gatsby.js - https://www.gatsbyjs.org/docs/porting-from-create-react-app-to-gatsby/
Next.js - https://nextjs.org/docs#custom-document
Netlify - https://dev.to/joelvarty/prerender-your-spa-using-netlify-for-better-seo-3h87
React-snap - https://web.dev/prerender-with-react-snap/
Prerender.io - https://prerender.io/
Keen’s Server Side Rendered - https://medium.com/keen-studio/keens-server-side-rendered-react-wordpress-rest-api-boilerplate-bb58edb7cc0a
Razzle - https://reactresources.com/topics/razzle
React Helmet - https://github.com/nfl/react-helmet
Can anyone suggest what option I should choose that is the least painless.
I have headless wordpress as backend and reactjs client-side as frontend.
Or are there other faster options besides the prerendering?
Thanks.
IMO you really don't need to use a framework to achieve SSR if you want to keep control without turning your codebase into a blackbox and choose your own stack.
I created some boilerplate using Node Express. It supports:
SSR using StaticRouter on the server and BrowserRouter in the client
ES6 webpack transpilation + hot reloading both client and server and auto-updating browser
Redux, data preloading and client store hydration
https://github.com/kimgysen/isomorphic-react-setup
Last time I ran it, I noticed that I hadn't saved the favIcon in the public folder and perhaps there are some minor bugs that I will fix soon (I've fixed them in my projects but didn't update this repo because nobody looks at it anyway (lol!)), but what happens here isn't all that difficult to understand.
I created some basic SSR websites with it in a matter of hours.
I enjoy redux-observable to initiate server ajax calls before rendering the content (using forkJoin), but this is not included in the boilerplate (I haven't actually supported it since I uploaded the first time).
But in terms of setup, I don't really see a point in using a framework for this necessarily, it really isn't that painful / difficult to do yourself.
The benefit that I particularly like is that you don't depend yourself on the scope and dependencies of the framework. You don't get into trouble with things like 'the framework will support this feature or fix that bug in one of the upcoming releases'.
Although ultimately, it comes down to personal choice. So it's not like I want to downgrade these frameworks.
Note: The way Redux achieves pre-rendering is simply by adding Redux store (state) objects to the window object in the html that is sent back to the client.
Then at the client, the it initializes the stores with these objects.
So very simply, this is something that is easy to achieve, even if you decide not to implement any other SSR features.
to create server side applicantion with painless integration you can use my cli to generate a default configuration like create react app cli from facebook, https://github.com/ghondar/crassa
In an article I read that
React uses server-side rendering.
But in another articles I came across this:
Client-Side-Rendering is a relatively new approach to rendering
websites, and it didn't really become popular until JavaScript
libraries started incorporating it into their style of development.
Some notable examples are Vue.js and React.js
Now Which statement is correct?
When I use create-react-app and run npm start, it seems to me that React uses the Client-Side-Rendering. isn't it?
It’s client side. But React, like some other client side libraries, can be used on the server to prerender it with node, usually for SEO.
Out of the box it renders on the client side.
But, if you have a requirement to render pages on a server, you can achieve this with:
Next.js or
Hypernova or any other tool (there is a bunch of them nowadays!)
Note, that SSR will require a bit more experience than a regular React app.
The main goal of this approach is to allow search engine robots crawl information form web pages(SEO).
create-react-app uses client side rendering by default. There are some tools like next js and gatsby js which pre-render pages on the server side. You can also do Server Side Rendering from scratch.
A few years on from the last answer, it is now quite difficult to implement a client-only React app - serving it on Node is trivial and absolutely what it expects, trying to use it as a client library with other server-side support is more of a challenge and documentation about how to do this is patchy and much of it out of date.