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.

• React test strategies — user observable behaviour vs implementation details
• Testing custom hooks with Enzyme

Test Strategies

There are broadly two strategies to test our React codebase.

1. Testing user observable behaviour
2. Testing implementation details

Testing user observable behaviour

Testing user observable behaviour means writing tests against components that test

• how the component is rendered
• how the component is re-rendered when user interacts with the DOM
• how props/state control what is rendered

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

• Amazing Dev Experience
• Pre-baked optimizations
• Generated site is super fast
• Out of the box support for GraphQL

Deploy Gatsby sites anywhere

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>…