β Ultra fast React boilerplate App (with SSR)
Introduction
React App with SSR Server Side Rendering. Webpack 5 installed manually. In dev mode we use live reload thanks to webpack-dev-middleware & webpack-hot-middleware modules.
Main modules used are redux-saga, loadable-component, react-jss and typescript.
Check out this app in live react-easy-ssr.herokuapp.com
Table of contents
Motivations
All this project is turned about SSR Server Side Rendering. And this is not an easy task. This would be legitimate to wonder why do we make such a complicated setup ?
You can use a Framework to do all of this, but to me you are locking yourself behind walls.
You can use Next.js or Gatsby.js but you will loose some powerful React functions.
React is a library, then we would say don't put yourself in a framework. Which is great by the way ;)
Please find the list of disadvantages of frameworks
- The
React-routermodule : you won't be able to handle this wonderful module, so bad withNext.jsyou create a file and it's added to your router automaticallyπ . - You won't have access to what happen on the Server Side. Just go to this project's page and you are done mate
π³ - According to
Next.jsyou can just installredux-thunknot the other ones, so bad how can we play withredux-sagaorredux-observable?π‘ - You won't be able to touch the webpack compilation and all the parameters (what if you want to put the polyfills in dynamic imports because modern browsers don't need them you make win 119kb at opening time). How can you manage the complex module
workbox-webpack-pluginto make a PWA, apparently it's already all done by Next.js look at that this messy code, we doubt it's done like you want. Look at this poor guy, it took him 2 years (from 2017 to 2019 lol) to make something special works with an easy webpack plugin check the github issueπ - You won't ever be able to use
renderToNodeStreamwith Next.js & Gatsby.js forget it. You will only be able to use the old one React functionrenderToString, so bad just check this github issue on their roadmap and for Gatsby.js they are even not talking about this check their issues. To me you can't make a switch to use one function or the other just with a boolean parameter true or false. It requires you to change part of the App's architecture, and also some modules you are using may not be compatible with (redux-sagaandreact-jssfor example but we'll see this that later) - Do you find other reasons why not to use a framework ? make a contribution and commit something here
We are making this because we need to make lobbying us, the developers. Upper-layer module of React are kind of side effect of open source community perfectionism. We are making upper-layer module of upper-layer module WTF ?
Getting started
Clone the repo
git clone https://github.com/tomtom94/react-easy-ssr.git
cd react-easy-ssr
Start in dev mode
npm install
Run dev mode with
npm run dev
it's gonna start an hot dev middleware with an express server ;) ready to work http://localhost:3000
Start in production mode
With Node.js
npm install
Write in your server provider the environment variables BACKEND_BASE_URL
Run build mode with
npm run build
it's gonna build in dist/
Then run in production mode
npm run start
;) it's gonna start the only one SSR express server out of the box for internet http://localhost:3000 or environment port used.
With Docker
docker build -t react-easy-ssr .
docker run -p 80:80 react-easy-ssr
Then open http://localhost:80
Must know about the app
You better use a good search engine like Qwant.com, don't use Google. please.
Contributors and mainteners
If ever you wanna work on this project, it's recommended to use prettier and eslint on your IDE (Visual Studio Code for example). Just note by default prettier don't touch .ts and .tsx extension files, you must make a speacial manipulation in Visual Studio Code in your settings.json.
Continuous Integration and Continuous Delivery
When pushing or merging on master branch, you can trigger Github Actions with a commit message that includes #major, #minor or #patch.
Example of commit message in order to start a deployment :
git commit -m "#major this is a big commit"
git commit -m "#patch this is a tiny commit"
Checks to do sometimes
- Check typescript
npm run tsc - Check eslint
npm run lint - Check prettier
npm run prettier
Components
The main rule is we don't use a frontend framework. All components come from wherever we need it, but we are not stick to one. No need of material-ui, no need of bootstrap etc... However we are used to copy past source code from them. For example we made a copy past of the wonderfull material-ui <Grid /> which is so much powerful check it out in this repo. We don't use many components that generate their own css stylesheet, because we need to control this carefully in order to make the famous SSR.
style-components and fontawesome modules are also installed if ever you wanna use it. And yes we care of them for the SSR also.
Please note we don't use classical CSS style. We use JSS (it means js in css). material-ui module also uses react-jss this is why we didn't installed material-ui else it would be stupid to generate twice the react-jss stylesheet on the SSR, and inefficiente to make an ultra fast App.
Either you install material-ui and you make all your css components with it (which is recommended if you do this for big company), or you get free and install react-jss like we did.
Data-fetching and SSR
Let's see how we fetch our data to feed our redux store. You can find this code in the <Movies /> component.
const willMount = useRef(true)
if (willMount.current && !process.env.BROWSER) {
dispatch(triggerMovies('GET_MOVIES'))
willMount.current = false
}
useEffect(() => {
dispatch(triggerMovies('GET_MOVIES'))
}, [dispatch])
- 1st part is only for server side, we dispatch the redux action : with
useRefyou can be sure the action won't be trigger multiple times in an infinite loop. - 2nd part is only for client side, we dispatch the redux action : but when you trigger this action there is a redux-saga selector which will check if data hasn't been already fetched during 1st part, if yes no need to fetch again.
This way your App is able to fetch data on the server & client side independantly.
ES6 Imports possible in JSX
Webpack setup only allows us to import files with ES6 in type
- .js .jsx .ts .tsx
- .png .jpe .jpeg .gif .ico
- .woff .woff2
- .css (remember
react-jssgenerates its own stylesheet via its own plugins, not via webpack loaders)
You can add more Webpack loader to your project...
Some disadvantages
-
With this configuration you can't use the powerful React function unveiled in 2018 called
renderToNodeStream. We must use the old one which is (from 2015)rendeToString. But no worries 90% of React Apps are on the old onerendeToString. List of modules not compatible withrenderToNodeStream(We are telling you the ones we are sure of, this is not an exhaustive list) -
Another important issue to know is the split code, the first time your frontend server reads one of your page it'll be blind of redux actions. This is so much interesting try to investigate yourself (use Postman and check if you have data in your redux store in the
__PRELOADED_STATE__window attribute, turn off and on your server check again in Postman, then refresh again) This is in fact a normal behavior check this issue on github. After a new deployment the first time you render a page, data-fetching during SSR is somethingloadable-componentcould not carry about. So the Google robot would not be able to treat a complete page in the DOM (this would be empty of data from the redux store except if another user has already opened this page before the Google robot) in this case only the client side will render. To conclude your app must always be able to render on the server & client side independantly.
Let's illustrate this last point with an example : you have 5 million pages to display with 5 React routes, each route render a component which deals with 1 million different pages, you just have to open 1 page (by yourself or a crawler like Google robot, Bing robot etc...) and the other 999999 will render perfectly.
Please note, in the world there are approximately 10 big crawlers (Russian, American, European, Asian...) which will open a page around every 20 seconds each on your App, this is a statistic home made but quite reliable. Just watch by yourself in your Nginx router who opens your page it's written ;) This is something to take into account for your servers performances, internet network is crazy busy when you have 5 million pages for real in a sitemap.xml. Don't think Google robot would read your App if you just do CSR Client Side Rendering. You don't make loose time to crawlers if you wanna have a good SEO score in search engines, moreover if you have 5 million pages to crawl.
According to my statistics I just said above this would take more than 3 years in the best case scenario for the Google robot to crawl all your 5 million pages this is why you can play with a parameter in your sitemap.xml files to set priorities in pages to crawl first.
I want to use renderToNodeStream to make a top notch app
Then you must use redux-thunk and/or a apollographql which is gonna give you easy promises to handle on server side, but make the right choice. And don't use react-jss, just use a classical SASS, LESS or CSS style. And you are good to go.
Notes
If ever you wanna brainstorm, download my resume you are gonna find my phone number