Progressive Rendering is the technique of sequentially rendering portions of a webpage in the server and streaming it to the client in parts without waiting for the whole page to rendered.
Note: The content of this post may be relevant to all types of servers but written within the context of a node.js server. The perf metrics are assumptive and may differ based on network bandwidth and latency.
To understand progressive rendering we must first understand how client side rendering and server side rendering work.
Client side rendering is the technique in which the server sends a simple HTML without any content in the body
and script tags in the head
. …
Hands down
console.log()
was, is and will always be the greatest debugging tool of all time.
React team launched a new version of the React Dev Tools (v4) a few weeks ago and it’s fantabulous. It gives you debugging superpowers to navigate through your tree, trace data flow, spot weak links and optimise for perf.
There are two separate tabs (Components, Profiler) now as opposed to the old version which had only one React tab.
This article is also cross-posted in -
DEV — Cache Busting a React App
TL;DR — SemVer your app and generate a meta.json
file on each build that won't be cached by the browser. Invalidate cache and hard reload the app when there's a version mismatch. Note: The examples and explanations in this post are React based. But the strategy will work with any web application/framework.
As great as caching is — cache invalidation has been a struggle for a long time now. Invalidating the cache of a web app that’s loaded in the browser is hard. …
This article is also cross-posted in -
DEV — Cache Busting a React App
TL;DR — SemVer your app and generate a meta.json
file on each build that won't be cached by the browser. Invalidate cache and hard reload the app when there's a version mismatch. Note: The examples and explanations in this post are React based. But the strategy will work with any web application/framework.
As great as caching is — cache invalidation has been a struggle for a long time now. Invalidating the cache of a web app that’s loaded in the browser is hard. …
TL;DR — Wrap your custom hook in a component and shallow render it to test implementation details.
There are broadly two strategies to test our React codebase.
Testing user observable behaviour means writing tests against components that test
Consider the following component — Greet
function Greet({ user = 'User' }) {
const [name, setName] = React.useState(user);
return <div onClick={() => setName('Pinocchio')}>Hello, {name}!</div>; …
Gatsby is all the rage now, thanks to the amazing team behind the fancy and easy-to-use framework. I’m not going to go into the details of why you should use Gatsby if you’re building a static website. There are a ton of posts out there that say just that.
Here’s an excellent article on why — Why you should use GatsbyJS to build static sites
These are my top reasons
Since Gatsby generates static files, you can deploy it anywhere.
But the easiest and quickest option would be to deploy your site to GitHub Pages. …
TL;DR — You can render viewport specific components in React with a one-liner
React is awesome and the whole world agrees to it unanimously. Development is a whole lot faster and easier when we look at everything as components. Since everything is JavaScript driven, React renders only the code that is necessary based on application’s state. It doesn’t matter if you have over a thousand components and tens of thousands of lines of code. If you lazy load your components, you load only what’s necessary for the user and I think that is the biggest win with using React.
That being said, have you ever wondered what happens when you write media queries in your React codebase? …
TL;DR — You can render viewport specific components in React with a one-liner
React is awesome and the whole world agrees to it unanimously. Development is a whole lot faster and easier when we look at everything as components. Since everything is JavaScript driven, React renders only the code that is necessary based on application’s state. It doesn’t matter if you have over a thousand components and tens of thousands of lines of code. If you lazy load your components, you load only what’s necessary for the user and I think that is the biggest win with using React.
That being said, have you ever wondered what happens when you write media queries in your React codebase? …
TL;DR — You can render browser specific content in React with a one-liner.
Have you ever wanted to put up a banner for all your IE users and ask them to try your site in Chrome/Firefox?
With RenderInBrowser component you can render content specific to browsers.
As promised in my post a few weeks back, I’ve ported the code from my other project, wrote thorough tests and created a standalone React library to render content only in specified browsers.
The syntax is too simple.
If you want to render something only in Chrome,
<RenderInBrowser only chrome>
<div>
Whoa! This super duper line will be rendered only in Chrome
</div>…
TL;DR — You can render browser specific content in React with a one-liner.
Have you ever wanted to put up a banner for all your IE users and ask them to try your site in Chrome/Firefox?
With RenderInBrowser component you can render content specific to browsers.
As promised in my post a few weeks back, I’ve ported the code from my other project, wrote thorough tests and created a standalone React library to render content only in specified browsers.
The syntax is too simple.
If you want to render something only in Chrome,
<RenderInBrowser only chrome>
<div>
Whoa! This super duper line will be rendered only in Chrome! …
About