Forem: Dinesh Pandiyan

Build Static Blogs with Keystone

Dinesh Pandiyan — Thu, 08 Sep 2022 23:04:53 +0000

TLDR: A local Keystone server to author content combined with Next.js static HTML export gives you a powerful tool to generate static blogs.

Keystone Static Blog is an open source template to build static blogs with Keystone and Next.js.

The template comes bundled with lots of goodies —

Beautiful, performant and fully responsive blog template.
Built with Tailwind and it comes with a nice dark/light mode that's easily customisable.
SEO optimised and accessible from the start. Lighthouse score is 100 for both SEO and Accessibility.

GitHub: keystone-static-blog
Preview: staticblogswithkeystone.netlify.app

Here's how it works

Content is authored in your local environment using Keystone's powerful rich text editor.
Content is fetched from Keystone's auto-generated GraphQL API during build-time.
The blog is prerendered as a static website using Next.js's static HTML export.

Content authoring with Keystone

Keystone is a powerful backend framework to build content driven websites. Keystone operates on schema driven development mental model where you describe the schema you want in JavaScript and Keystone automatically generates a fully functional GraphQL API for you in seconds. And to top it off, Keystone comes built-in with a feature-rich Admin UI to manage your content visually.

Keystone's document field is powered by an incredible rich text editor. All the default components (headings, paragraphs, bold, italics, code blocks, etc) that you usually use to write a blog post are supported by the editor out of the box. The editor exposes an intuitive API to build your own custom components and that's what makes this blog template stand out. This template includes a few custom components in the editor that would be useful in a blog post. Eg. Hero image, Tweet embed, YouTube embed, callout, custom blockquote and custom code blocks with syntax highlighting using prism.

Keystone gives us a GraphQL API right from the get go to work with our data, meaning, applications built with Keystone are Jamstack ready right from the start.

On top of that, Keystone supports SQLite database. SQLite is a super compact and convenient file system based database. This means that in an SQLite based Keystone server, you don't have to host your server anywhere and instead use it only in your local environments, all your data can live alongside your code as a simple, small file and changes to your content can be committed to your repo just like any other file. 🤯 This is what makes this whole template a super powerful alternative to MDX based blogs where the workflow is exactly the same — make changes in your local and commit your content to your repo.

Next.js static export

The template is just a simple prerendered static blog built with Next.js static HTML export. When you run the build, content data is fetched from the local keystone GraphQL API and the entire blog is exported as a bunch of HTML, CSS and JavaScript files that can be statically hosted anywhere for free.

Tailwind makes wire-framing redundant

The blog template is built using Tailwind and comes with dark/light mode. The greatest thing about Tailwind is not the tool itself but its opinionated design tokens and the preset based approach (popularly known as utility based approach) to building and styling interfaces. Even if you don't know how your interfaces are exactly going to look, you can play around with the presets and somehow end up with a beautiful looking website. That's how good the default Tailwind design tokens are. Every time I work with Tailwind I feel like a magician pulling user interfaces out of thin air.

Comparison with MDX based static blogs

Authoring content using MDX is great. I love it. I use MDX to author content in a lot of projects. You write something in a file and commit to your repo, it's as simple as that. But simplicity also means that it's limited. Customisation is a pain. If you want to build your own custom components (Embedded videos, tweets, a deeply nested component, etc) to use in your content you gotta jump through hoops and hope someone has made a plugin that suits your requirements. And forget about visually looking at your content while authoring. And that's why I prefer to author my content with a visual editor like Keystone's document editor that also supports MDX syntax to author content.

At the end of the day, MDX and local Keystone based static blogs are more of less the same in terms of how you ship content —

You author content in your local environment.
You prerender your blog.
You commit your content along with your code to your repo.
You host your prerendered website as static files.

That's all folks

I built this template as an experiment to see if Keystone could be a good alternative for MDX and had a ton of fun building it. I'm gonna add a handful of themes soon to spice things up.

There are endless possibilities to what we could build with well structured schema driven content.

Fork the template and make it yours. That's what I did for my website as well. Say hi to me on Twitter. Happy Blogging! 👋

10-tweet threads are the new micro blogs

Dinesh Pandiyan — Sat, 05 Oct 2019 06:34:55 +0000

I recently stumbled across Chris's @chrisachard 10-tweet-thread about React hooks. It was pure genius.

Writing more in less helps stay on point without beating around the bush
It helps readers consume more knowledge from less content
Chances of consuming knowledge from a tweet is more when compared to a blog post. (I read at least a 100 tweets a day whereas I only skim around ~10 blog posts a day)

Blog posts are more suited for in-depth elaborate dissection of a topic. But I personally feel tweet threads make it easy to consume knowledge if the content format is short and a can be summarised.

In that spirit I am planning to write more tweet threads on short topics that fit into 10 tweets and share it here.

Here's my first thread — CSR vs SSR

// Detect dark theme var iframe = document.getElementById('tweet-1180313818825576448-130'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1180313818825576448&theme=dark" }

And second — React Dev Tools

// Detect dark theme var iframe = document.getElementById('tweet-1180324978278879232-768'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1180324978278879232&theme=dark" }

Would love to hear your thoughts on this.

React Dev Tools — Debug Like a Ninja

Dinesh Pandiyan — Fri, 20 Sep 2019 06:26:04 +0000

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.

New Dev Tools has great many improvements over the old version. To highlight a few —

🏎 Faster
🎣 Hooks support
🧐 Advanced tree filter
🤠 Better search UX
👮‍♀️ Badges for HOCs
🎯 Remembers selection after page reload

Top 10 Features

Dev Tools can do a lot of things. We’re are not going to dive into the nitty gritty details of each and every feature. Instead we’ll take a look at the top 10 helpful features that help us save time and write better React code.

Components Tab

Live edit state/props
Search through tree
Advanced tree filter
Rendered by
Owners tree
Quick Navigation
Utils

Profiler Tab

Profile initial mount
Why did this render?
Rendered at

1. Live Edit State/Props

You can live edit the state and props of a component and instantly see the results in the page.

Since the gif is broken, you can view it here.

2. Search Through Tree

The search bar comes handy when you want to quickly find and jump to a component in the tree. Now that the Dev Tools can remember stuff the selected node is saved between reloads and you don’t have to repeat the action every time you reload the page.

3. Component Filter

Filter is a powerful feature to reduce visual noise and focus on what matters at the moment in a huge tree. You can filter with a variety of options like context, HOCs, host(DOM) nodes, component name, etc.

4. Rendered By

Rendered By is a list of owner/parent components that rendered the selected component. You can quickly jump to a parent component by selecting an entry from the list.

5. Owners Tree

Owners Tree gives you an eagle eye view of a particular component and its sub-tree and hides the rest of the component tree.

To enter into owners tree view, you have to double click a component in the tree.

6. Quick Navigation

Switching between Elements tab (browser dev tools) and Components tab (react dev tools) is pretty easy and the corresponding node is auto selected in these tabs.

To find the corresponding DOM node in the Elements tab, select the component and click the small eye icon on the right pane. It will take you to the Elements tab with the corresponding DOM node selected.

To find the corresponding React node from Elements tab, just select a node in Elements tab and click the Components tab. React Dev Tools will automatically select the corresponding component.

7. Utils

Components tab offers three small handy utils.

Suspend component
Inspect matching DOM element
Log component data to console

Suspend Component

You can easily switch between the waiting(loading) and resolved states of Suspense components.

Inspect matching DOM element

We already saw this in Quick Navigation. You can select a component and click the eye icon on the right pane to jump to its corresponding node in Elements tab to inspect it.

Log component data to console

This is a handy utility that logs the entire component meta data to the console. The log gives details like props, hooks, corresponding DOM nodes and the component file location in the file system.

To log component data to console, select the component and click the small bug icon in the right pane.

Intro to Profiler

The next three features are going to be about the Profiler. Before diving into them, we’ll take a look at how profiler works and the key metrics that are used during profiling.

Every profiling session has two important colour graphs —

Commit graph
Component graph

Commit Graph

Commit graph gives you a list of commits (whole tree) during the session. Each commit denotes a user activity or side-effect that triggered a render in the tree.You will see it coloured from orange to green with orange denoting the costliest (took most time) commit and green denoting the cheapest (took least time) commit.

Component Graph

Component graph gives you info on which component rendered during a single commit. You can select each commit from the commit graph to see its component graph. It is also colour coded with cost information —

Dark Grey — Component did not render but a part of its sub-tree rendered
Transparent Grey — Neither the component nor its subtree rendered
Coloured — Both the component and its entire subtree rendered

8. Profile Initial Mount

Initial mount and first render is usually a perf heavy op in most React applications. In older versions of Dev Tools, it was impossible to profile and audit the initial mount phase. But the latest version provides an option to profile and audit the initial mount.

9. Why Did This Render?

This is the most powerful feature of the Dev Tools yet and it tells you why a component rendered during a profiling session. A component might have rendered for one or many of these reasons —

Props changed
State changed
Hooks changed
Parent component rendered

You can profile an activity and see why a component rendered during the profiling session to spot weak links and prevent unnecessary renders in the tree.

Note: You have check this setting — “Record why each component rendered while profiling” to see this info in the right pane of the Profiler Tab.

10. Rendered At

Rendered At info on the right pane gives you two time metrics —

When exactly the component rendered during the profiling session
How long it took for the component to render during the profiling session

Eg. 2.2s for 2.3ms

Here, 2.2s means the component rendered at 2.2s(2200ms) from the start of the profiling session which is 0s. And 2.3ms is the amount of time it took for the component to render.

Since the gif is broken, you can view it here.

That’s all folks.

If you’re interested in exploring all the features, the React team has built a site just for that — Interactive Dev Tools.

Play around with Dev Tools and drop a comment below or start a conversation with the author in Twitter on what you think.

This post is a cross post of the original post from The Thinkmill Blog.

React — Access custom params in handlers the right way

Dinesh Pandiyan — Thu, 06 Jun 2019 14:13:57 +0000

TL;DR - You can access render time values in handlers without having to use anonymous arrow functions. Hint — leverage data attributes.

React is great in so many aspects and it gives us the freedom to do things in different ways by being less opinionated (or non opinionated).

In recent days, especially after the release of hooks, the community has been fussing around a lot on reference equality and how anonymous arrow functions in renders are not good for performance.

We are not going to deep dive into why or how using arrow functions during render affects the performance (or it does not). Here are two contrasting tweets for context.

// Detect dark theme var iframe = document.getElementById('tweet-1131707595880898560-474'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1131707595880898560&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1135936248386736128-841'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1135936248386736128&theme=dark" }

When

We mostly use arrow functions during render only to pass custom parameters to event handlers.

For example, this is a common use case —

const MyComp = () => {
  const handleClick = (e, id) => {
    // handle click and use id to update state
  }

  // id comes from state
  return (
    <div onClick={(e) => handleClick(e, id)}>Hello World!</div>
  )
}

How

Instead of using an anonymous arrow function here, we could leverage data attributes and access values from the event object.

const MyComp = () => {
  const handleClick = (e) => {
    const id = e.target.dataset.id
    // handle click and use id to update state
  }

  // id comes from state
  return (
    <div data-id={id} onClick={handleClick}>Hello World!</div>
  )
}

Advantages

This approach has a lot of advantages —

You can memoize the callback pretty easily if needed.

const MyComp = () => {
  // id comes from state
  const handleClick = React.useCallback((e) => {
    const id = e.target.dataset.id
    // handle click and use id to update state
  }, [id])

  return (
    <div data-id={id} onClick={handleClick}>Hello World!</div>
  )
}

You don't create a new function during component render which saves additional computation cost during vdom diffing.
If child components that use React.memo take this handler as a prop, you don't have to write custom areEqual method to circumvent referential integrity issues with anon arrow functions.

Keep in mind that all data attributes return String values even if you pass in other primitive types. So it's a good practice to coerce your value while extracting from dataset.

const id = e.target.dataset.id // this will be String

const id = Number(e.target.dataset.id) // convert to type if needed

I have created a codesandbox to demonstrate how it works — Custom Params In Handlers

You are amazing! Have a great day! ⚡️

Cache Busting a React App

Dinesh Pandiyan — Sun, 14 Apr 2019 13:59:25 +0000

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. But invalidating the cache of a web app that's saved to the home screen is even harder.

A quick intro to caching —

Server caching: Web servers cache the resources when they are requested for the first time. Second time onwards, the resources are served from the server cache. There's a lot more to this — CDN, origin servers, edge servers, etc but we'll not go into all that. Invalidating server cache is quite straight forward as we have control over our server and on each new deploy, we could either automatically or manually clear the old cache.

Browser caching: Browsers also cache the resources in their own way. When a site is loaded for the first time in the user's browser, the browser decides to cache some resources (mostly assets like images, js and css) locally and the next time the user visits the same site, the browser serves the resources from the local cache. Since we don't have control over the user's browser, clearing cache in the user's browser has always been a bit of a struggle in the past. With cache headers and with build tools like webpack generating unique chunks on each build, it's a becoming a bit easier to manage, but still, it's not without pitfalls.

Here are some of the gotchas with browser caching —

Browsers tend to ignore cache validation some times if the site is refreshed in the same tab — if the user pins the tab, there's a good chance the site will be loaded from browser cache even if the server cache is cleared.
If your app is registering a service-worker, then the service worker cache will be invalidated only if the user opens the site in a new tab. The user will be stuck with the service worker cache forever if the tab is never closed.
If the user adds the site to home screen in mobile/tablet, then the browser cache will be invalidated only if the user explicitly quits the app — it's almost the same as having the same tab open in the browser. I know people who don't quit their home screen apps for months.

Ideally, caching helps to load the site faster. Disabling cache is not the answer. It's also not reliable as you cannot control the behavior of your user's browser. We want to figure out a way to clear the browser or service worker cache every time a new version of our app is deployed to the server.

A simple yet effective approach

SemVer your deploys
Bundle the app version into the app
Generate a meta.json file with the app version on each build
Fetch meta.json on load and compare versions
Force clear cache and hard reload when there's a version mismatch

SemVer your deploys

Version all your deploys with SemVer. I personally use these three npm commands that automatically increments the package version and creates a git commit along with a corresponding version tag.

npm version patch — for releases with only bug fixes
npm version minor — for releases with new features w/ or w/o bug fixes
npm version major — for major releases or breaking features

Remember to push your commit with --tag attribute — git push origin master --tags

Bundle the app version into the app

Parse the package version during webpack build (or relevant build tool) and set a global variable in the app so you can conveniently check the version in the browser console as well as use this to compare with the latest version.

import packageJson from '{root-dir}/package.json';
global.appVersion = packageJson.version;

Once this is set, you will be able to check the app version in the browser console by typing appVersion.

Generate a `meta.json` file with the app version on each build

Run a script to generate a meta.json file in the public dir of your app.

Add a prebuild npm script that will generate the meta.json file before each build.

/* package.json */

{
    "scripts": {
        "generate-build-version": "node generate-build-version",
        "prebuild": "npm run generate-build-version",
        // other scripts
     }
}

/* generate-build-version.js */

const fs = require('fs');
const packageJson = require('./package.json');

const appVersion = packageJson.version;

const jsonData = {
  version: appVersion
};

var jsonContent = JSON.stringify(jsonData);

fs.writeFile('./public/meta.json', jsonContent, 'utf8', function(err) {
  if (err) {
    console.log('An error occured while writing JSON Object to meta.json');
    return console.log(err);
  }

  console.log('meta.json file has been saved with latest version number');
});

After each build, once you deploy the app, meta.json can be accessed using the path /meta.json and you can fetch the json like a REST endpoint. It won't be cached by the browser as browsers don't cache XHR requests. So you will always get the latest meta.json file even if your bundle files are cached.

So if the appVersion in your bundle file is less than the version in meta.json, then we know that the browser cache is stale and we will need to invalidate it.

You can use this script to compare semantic versions —

// version from `meta.json` - first param
// version in bundle file - second param
const semverGreaterThan = (versionA, versionB) => {
  const versionsA = versionA.split(/\./g);

  const versionsB = versionB.split(/\./g);
  while (versionsA.length || versionsB.length) {
    const a = Number(versionsA.shift());

    const b = Number(versionsB.shift());
    // eslint-disable-next-line no-continue
    if (a === b) continue;
    // eslint-disable-next-line no-restricted-globals
    return a > b || isNaN(b);
  }
  return false;
};

You can also find this code in my GitHub example

Fetch `meta.json` on load and compare versions

When the App is mounted, fetch meta.json and compare the current version with the latest version in the server.

When there is a version mismatch => force clear cache and hard reload
When the versions are the same => Render the rest of the app

I have built a CacheBuster component that will force clear cache and reload the site. The logic will work for most of the sites but can be tweaked for custom cases depending on the applications.

/* CacheBuster component */
import packageJson from '../package.json';
global.appVersion = packageJson.version;

const semverGreaterThan = (versionA, versionB) => {
    // code from above snippet goes here
}

export default class CacheBuster extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      loading: true,
      isLatestVersion: false,
      refreshCacheAndReload: () => {
        console.log('Clearing cache and hard reloading...')
        if (caches) {
          // Service worker cache should be cleared with caches.delete()
          caches.keys().then(function(names) {
            for (let name of names) caches.delete(name);
          });
        }
        // delete browser cache and hard reload
        window.location.reload(true);
      }
    };
  }

  componentDidMount() {
    fetch('/meta.json')
      .then((response) => response.json())
      .then((meta) => {
        const latestVersion = meta.version;
        const currentVersion = global.appVersion;

        const shouldForceRefresh = semverGreaterThan(latestVersion, currentVersion);
        if (shouldForceRefresh) {
          console.log(`We have a new version - ${latestVersion}. Should force refresh`);
          this.setState({ loading: false, isLatestVersion: false });
        } else {
          console.log(`You already have the latest version - ${latestVersion}. No cache refresh needed.`);
          this.setState({ loading: false, isLatestVersion: true });
        }
      });
  }

  render() {
    const { loading, isLatestVersion, refreshCacheAndReload } = this.state;
    return this.props.children({ loading, isLatestVersion, refreshCacheAndReload });
  }
}

And we can use this CacheBuster component to control the render in App component

/* App component */
class App extends Component {
  render() {
    return (
      <CacheBuster>
        {({ loading, isLatestVersion, refreshCacheAndReload }) => {
          if (loading) return null;
          if (!loading && !isLatestVersion) {
            // You can decide how and when you want to force reload
            refreshCacheAndReload();
          }

          return (
            <div className="App">
              <header className="App-header">
                <h1>Cache Busting - Example</h1>
                <p>
                  Bundle version - <code>v{global.appVersion}</code>
                </p>
              </header>
            </div>
          );
        }}
      </CacheBuster>
    );
  }
}

You can also find the code for both these components here —

CacheBuster - CacheBuster.js
App - App.js

Force clear cache and hard reload when there's a version mismatch

Every time the app is loaded, we check for the latest version. Depending on whether the app version is stale or not, we can decide to clear cache in different ways.

For instance,

You can hard-reload before rendering the app
You can show a modal/popup asking the user to click a button and trigger a hard-reload
You can hard-reload when the app is idle
You can hard-reload after a few seconds with setTimeout()

You can find the entire code from this post with a working example in this repo — cache-busting-example

That's all folks. If you have any feedback for this approach (good and bad), do let me know in the comments.

Cache busting is fun. 🎉

React Hooks: Test custom hooks with Enzyme

Dinesh Pandiyan — Sat, 23 Mar 2019 11:47:08 +0000

TL;DR - Wrap your custom hook in a component and shallow render it to test implementation details.

What you will learn

React test strategies
- user observable behaviour
- implementation details
Testing custom hooks with Enzyme

Test Strategies

There are broadly two strategies to test our React codebase.

Testing user observable behaviour
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>;
}

Testing the user observable behaviour in Greet would mean

test if Greet is rendered without crashing
test if Hello, User! is rendered when user prop is not passed
test if Hello, Bruce! is rendered when Bruce is passed as value to user prop
test if the text changes to Hello, Pinocchio! when the user clicks on the element

Testing implementation details

Testing implementation details means writing tests against state logic that test

how the state is initialized with default/prop values
how the state changes when handlers are invoked

Consider the same component - Greet

function Greet({ user = 'User' }) {
  const [name, setName] = React.useState(user);

  return <div onClick={() => setName('Pinocchio')}>Hello, {name}!</div>;
}

Testing implementation details in Greet would mean

test if name is set to default value User when user prop is not passed to Greet
test if name is set to prop value when user prop is passed to Greet
test if name is updated when setName is invoked

Testing custom hooks with Enzyme

Note: Please make sure your React version is ^16.8.5. Hooks won't re-render components with enzyme shallow render in previous versions and the React team fixed it in this release. If your React version is below that, you might have to use enzyme mount and .update() your wrapper after each change to test the re-render.

Testing implementation details might seem unnecessary and might even be considered as a bad practice when you are writing tests against components that contains presentational (UI) logic and render elements to the DOM. But custom hooks contain only state logic and it is imperative that we test the implementation details thoroughly so we know exactly how our custom hook will behave within a component.

Let's write a custom hook to update and validate a form field.

/* useFormField.js */

import React from 'react';

function useFormField(initialVal = '') {
  const [val, setVal] = React.useState(initialVal);
  const [isValid, setValid] = React.useState(true);

  function onChange(e) {
    setVal(e.target.value);

    if (!e.target.value) {
      setValid(false);
    } else if (!isValid) setValid(true);
  }

  return [val, onChange, isValid];
}

export default useFormField;

As great as custom hooks are in abstracting away re-usable logic in our code, they do have one limitation. Even though they are just JavaScript functions they will work only inside React components. You cannot just invoke them and write tests against what a hook returns. You have to wrap them inside a React component and test the values that it returns.

custom hooks cannot be tested like JavaScript functions
custom hooks should be wrapped inside a React component to test its behaviour

Thanks to the composibility of hooks, we could pass a hook as a prop to a component and everything will work exactly as how it's supposed to work. We can write a wrapper component to render and test our hook.

/* useFormField.test.js */

function HookWrapper(props) {
  const hook = props.hook ? props.hook() : undefined;
  return <div hook={hook} />;
}

Now we can access the hook like a JavaScript object and test its behaviour.

/* useFormField.test.js */

import React from 'react';
import { shallow } from 'enzyme';
import useFormField from './useFormField';

function HookWrapper(props) {
  const hook = props.hook ? props.hook() : undefined;
  return <div hook={hook} />;
}

it('should set init value', () => {
  let wrapper = shallow(<HookWrapper hook={() => useFormField('')} />);

  let { hook } = wrapper.find('div').props();
  let [val, onChange, isValid] = hook;
  expect(val).toEqual('');

  wrapper = shallow(<HookWrapper hook={() => useFormField('marco')} />);

  // destructuring objects - {} should be inside brackets - () to avoid syntax error
  ({ hook } = wrapper.find('div').props());
  [val, onChange, isValid] = hook;
  expect(val).toEqual('marco');
});

The full test suite for useFormField custom hook will look like this.

/* useFormField.test.js */

import React from 'react';
import { shallow } from 'enzyme';
import useFormField from './useFormField';

function HookWrapper(props) {
  const hook = props.hook ? props.hook() : undefined;
  return <div hook={hook} />;
}

describe('useFormField', () => {
  it('should render', () => {
    let wrapper = shallow(<HookWrapper />);

    expect(wrapper.exists()).toBeTruthy();
  });

  it('should set init value', () => {
    let wrapper = shallow(<HookWrapper hook={() => useFormField('')} />);

    let { hook } = wrapper.find('div').props();
    let [val, onChange, isValid] = hook;
    expect(val).toEqual('');

    wrapper = shallow(<HookWrapper hook={() => useFormField('marco')} />);

    // destructuring objects - {} should be inside brackets - () to avoid syntax error
    ({ hook } = wrapper.find('div').props());
    [val, onChange, isValid] = hook;
    expect(val).toEqual('marco');
  });

  it('should set the right val value', () => {
    let wrapper = shallow(<HookWrapper hook={() => useFormField('marco')} />);

    let { hook } = wrapper.find('div').props();
    let [val, onChange, isValid] = hook;
    expect(val).toEqual('marco');

    onChange({ target: { value: 'polo' } });

    ({ hook } = wrapper.find('div').props());
    [val, onChange, isValid] = hook;
    expect(val).toEqual('polo');
  });

  it('should set the right isValid value', () => {
    let wrapper = shallow(<HookWrapper hook={() => useFormField('marco')} />);

    let { hook } = wrapper.find('div').props();
    let [val, onChange, isValid] = hook;
    expect(val).toEqual('marco');
    expect(isValid).toEqual(true);

    onChange({ target: { value: 'polo' } });

    ({ hook } = wrapper.find('div').props());
    [val, onChange, isValid] = hook;
    expect(val).toEqual('polo');
    expect(isValid).toEqual(true);

    onChange({ target: { value: '' } });

    ({ hook } = wrapper.find('div').props());
    [val, onChange, isValid] = hook;
    expect(val).toEqual('');
    expect(isValid).toEqual(false);
  });
});

Rendering the custom hook and accessing it as a prop should give us full access to its return values.

If you're using useEffect hook in your custom hook, make sure you wrap the shallow or mount call with ReactTestUtils.act() to have the effects flushed out before assertions. Enzyme might support this internally soon but for now, this is required. More info on this here - hooks-faq.

act(() => {
  wrapper = shallow(<HookWrapper />);
});

All code snippets in this post can be found in the repo - testing-hooks with a working example.

Happy testing! 🎉

Don't build your portfolio with just React

Dinesh Pandiyan — Fri, 01 Feb 2019 07:03:32 +0000

TL;DR - Use React along with Gatsby or Next to build static public sites.

React is all the rage these days and IMHO developing websites feels a lot easier with React. Of course, you can use and favor other frameworks too but I'm gonna limit the context of this post to React affictionados.

Why you should use React

Component based
Pre-configured (for most part) starter with create-react-app
Faster development
React is AWESOME 🎉

Why you shouldn't use just React

DOM is constructed in the browser (client-side)
SEO implications
Higher Time to Interactive (TTI)

Let's get a little more into why all these things happen.

React loads the site into DOM after this line is invoked.

ReactDOM.render(<App />, document.getElementById('root'));

What this means it, the whole DOM, styles and behavior of the site is initialized only after the bundle.js is loaded and executed.

If you turn off JavaScript in your browser settings and open a React site, nothing will load and you will see only an empty page.

Unfortunately that's how search engines look at your site during indexing. So if you create your site with just React, only your page title will be indexed and nothing else inside your React code will be indexed.

Edit: Google executes JavaScript during indexing to a limited extent, meaning if you don't have content in first render or if render takes more than N secs, it skips the content. Also DuckDuckGo is becoming the de-facto search engine to a lot of folks in recent times and it's been my only search engine for more than a year now. And DuckDuckGo doesn't execute JavaScript during indexing. So relying on search engines to execute JavaScript is not a safe bet.

Other than SEO implications, loading your site without the DOM in the first load (paint) increases your TTI metric. If you could load the DOM in the first load before loading your scripts, you'll drastically improve the UX.

SSR and Static Site Generation for the Rescue

SSR Websites and Static Websites are two different things. SSR pages are rendered from a server on each request where as static pages are generated during build time.

If you use frameworks like Gatsby or Next, you can either generate static sites or create SSR pages.

In other words, if you turn off your JavaScript and load these sites, the whole DOM will be loaded as the pages are already rendered.

Ideally, only event handlers and complementary data should be loaded and attached after the first render.

Gatsby or Next?

If you are building a static public website, Gatsby will be the right tool.
If you are building a website that has a login and a lot of server side logic, Next will be the right tool.

Of course there are a lot other options and reasons to choose your right tool but personally these two will be enough for most preliminary requirements.

Other points to argue

You can create SSR pages with React but you will need to setup your server and everything manually. Next.js makes this whole process easier.
Google claims that it executes JavaScript recently while indexing, but I tried and it didn't work for me. We're not sure of the nuances of it.

Gatsby is ❤️

In other news, I'm totally smitten and unfathomably in love with Gatsby ❤️

I migrated my old portfolio from React to Gatsby exactly for the reasons discussed in this post. This is my new portfolio in Gatsby - Dinesh Pandiyan.

Going forward, I'm planning to build all my side projects in Gatsby this year. I created a Gatsby starter boilerplate with added configurations over default Gatsby starter - Gatsby Boilerplate.

My Gatsby based sites so far

Dinesh Pandiyan
tweetfancy.io
Another pet project in WIP stage. I'll probably launch it in a month.

You are amazing! ✨

Deploy Gatsby sites to GitHub Pages

Dinesh Pandiyan — Wed, 23 Jan 2019 15:11:42 +0000

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.

GitHub Pages

You can host static websites for free with GitHub Pages. You can have two types of websites hosted in GitHub Pages.

Personal Website - Repo name should be username.github.io and the site can be accessed at https://username.github.io
Project Website - Repo name can be anything and the site can be accessed at https://username.github.io/repo-name

All you gotta do is to push the static site to the repo with index.html at the root dir.

More info here - GitHub Pages

Deploy Gatsby sites to GitHub Pages

Gatsby generates your static site when you run the command gatsby build.

Only catch here is that GitHub Pages expect your site files to be in the root dir but Gatsby generates the site files in a dir called public. So we cannot host the source code and the public files in the same repo.

gh-pages is a really nice package that helps you push static sites to a GitHub repo from anywhere.

Steps

yarn add gh-pages --dev
Create a new dir scripts at project root and create a file deploy-github.js in scripts dir
Add this code to deploy-github.js

const ghpages = require('gh-pages')

// replace with your repo url
ghpages.publish(
  'public',
  {
    branch: 'master',
    repo: 'https://github.com/flexdinesh/flexdinesh.github.io.git',
  },
  () => {
    console.log('Deploy Complete!')
  }
)

Add a new npm script deploy:github in package.json

"deploy:github": "npm run build && node ./scripts/deploy-github"

Run the script and your static site will be up and running in a few seconds

Note: When you run the command, you will be asked to enter your GitHub creds in the command line before publish.

If you need further materials, you could take a look at the source code of my personal website Dinesh Pandiyan - Portfolio. It is deployed to both Netlify and Github Pages.

If you're looking for a good Gatsby starter template, I maintain a boilerplate with my pre-baked web setup - Gatsby Boilerplate. I usually fork this repo if I want to start with a new Gatsby site.

Happy Gatsbying! 🔥

Tweet in bold, italics and strikethrough text

Dinesh Pandiyan — Tue, 22 Jan 2019 16:37:19 +0000

TL;DR - I built a tool - tweetfancy.io to tweet in bold, italics and strikethrough text.

Ever fancied tweeting with bold, italics or ~~strikethrough~~ text?

Twitter doesn't allow its users to format tweets. But having an option to emphasize or call out a word or a phrase in a tweet might come in handy at times.

Announcing tweetfancy.io

I recently realized that the UTF charset has characters and symbols that look like bold, italics or ~~strikethrough~~ ascii characters. So I built a tool that generates these characters which could be copied and pasted into almost any website out there.

Write your original text in markdown
The editor will generate text for you to copy/paste
Tweet directly from the editor
Copy/Paste the generated text into any website (FB/Insta/etc)

Note: The generated characters are mathematical symbols and not actual English alphabets. So if you run them by a screen reader, you'll find that the reader reads them out by their symbol name. But then, all screen readers struggle reading smileys too (🎉🔥🚀🦄😎) and that doesn't stop us from using smileys. So,we might use this as well.

Here's the link - tweetfancy.io

Go bonkers tweeting in bold, italics or ~~strikethrough~~! Happy tweeting! 🎉

2018 - Year In Review

Dinesh Pandiyan — Fri, 04 Jan 2019 16:34:40 +0000

2018 has been an amazing year for me. I learnt new things, built a few things, wrote a handful of blog posts and met some amazing devs in the community. But above all, I became a better dev by learning and reflecting on my mistakes throughout. Here's a quick list down of how 2018 turned out to be an amazing year for me.

Things I built in 2018

Browser or Node - January
Typy - February
Dev Landing Page - March
Axios Retry Interceptor - March
React-Redux Boilerplate - March
React Render-In-Browser - May
React Socks - November
Typy v3 - December
React Socks Stable - December

Things I wrote in 2018

How I got started with Open-Source - February
Accessing Nested Objects in JavaScript - February
Short Circuit Assignment in JavaScript - February
Publish your own NPM package - March
Create your developer landing page with GitHub Pages - March
React-Redux Boilerplate with Best Practices - March
Upgrade to Webpack 4 - March
I Created My Portfolio with React and Some Magic - April
Render Browser Specific Content with React - May
Introducing Responsive React Components - November

Goal Stats

✅ Start with OSS (have over 10 actively maintained projects now)
✅ Become an active contributor to a repo that’s not mine (became one of the top contributors)
✅ Create and publish a library that others find helpful (have 7 libs now with 130k+ downloads)
✅ Build a portfolio
✅ Hit 1k reps in Stack Overflow (2.4k currently)
✅ Hit 1k followers in dev.to (2.2k currently)
✅ Learn Docker, ELK stack, reverse proxy
⚠️ Hit 700 followers in twitter (695 now)
❌ Build a website that others find helpful
❌ Learn GraphQL, serverless, web components

Summary

Started with OSS
Quit my awesome job to take on a challenging role
Moved to new country
Started contributing more in Stack Overflow
Started building and publishing libraries
Started writing about the things I learn and the things I build
Became a publisher in Hackernoon and Codeburst
All my write ups together have been viewed over 250k times (100k+ DEV and 150k+ Medium)
A few blog posts that I wrote got featured in other platforms and curations
Found awesome people in the community (twitter and dev.to) and drew inspiration from them

Dev principles I picked up in 2018

I want to wrap up this post by highlighting a few dev principles I learnt and strictly adopted in my workflow in 2018.

Code without tests is as good as no code at all
No Abstraction > Wrong Abstraction
Most optimization strategies you come up with will either result in premature-optimization or over-optimization. Optimize only when absolutely necessary.
Have a broader vision of the problem/solution but break it down and build in small portions incrementally
If you add a todo to improve later, you’ll never get back to it. So, do it now.

🥂 To another wonderful year full of opportunities and amazing people 🥂

2018: Year In Review

Dinesh Pandiyan — Tue, 18 Dec 2018 01:30:08 +0000

We are 12 days away from the end of another phenomenal year. I am going to write a Year In Review post in a week and tag it with #yearinreview hashtag. I encourage everyone else to do so as well. It will give you an opportunity to look back at what this year has brought for you and set some realistic goals for next year.

I will keep my post limited to this context but it can be anything you want to write about.

career progress
goals set
goals smashed
goals overdue
new things learnt
new achievements unlocked
old things taken care of
anything that made you happy

It's all about growing together.

What is the role of a developer advocate?

Dinesh Pandiyan — Sat, 24 Nov 2018 11:40:34 +0000

A few of high profile speakers in conferences and big companies have the designation "Developer Advocate".

What exactly does a Developer Advocate do?
Do they have a specific job description or is it an umbrella term for a wide range of roles?
Is someone in the Dev community a Developer Advocate or know someone who is one?

Forem: Dinesh Pandiyan

Build Static Blogs with Keystone

Here's how it works

Content authoring with Keystone

Next.js static export

Tailwind makes wire-framing redundant

Comparison with MDX based static blogs

That's all folks

10-tweet threads are the new micro blogs

React Dev Tools — Debug Like a Ninja

Top 10 Features

Components Tab

Profiler Tab

1. Live Edit State/Props

2. Search Through Tree

3. Component Filter

4. Rendered By

5. Owners Tree

6. Quick Navigation

7. Utils

Suspend Component

Inspect matching DOM element

Log component data to console

Intro to Profiler

Commit Graph

Component Graph

8. Profile Initial Mount

9. Why Did This Render?

10. Rendered At

React — Access custom params in handlers the right way

When

How

Advantages

Cache Busting a React App

SemVer your deploys

Bundle the app version into the app

Generate a meta.json file with the app version on each build

Fetch meta.json on load and compare versions

Force clear cache and hard reload when there's a version mismatch

React Hooks: Test custom hooks with Enzyme

What you will learn

Test Strategies

Testing user observable behaviour

Testing implementation details

Testing custom hooks with Enzyme

Don't build your portfolio with just React

Why you should use React

Why you shouldn't use just React

SSR and Static Site Generation for the Rescue

Gatsby or Next?

Gatsby is ❤️

Deploy Gatsby sites to GitHub Pages

Deploy Gatsby sites anywhere

GitHub Pages

Deploy Gatsby sites to GitHub Pages

Steps

Tweet in bold, italics and strikethrough text

Announcing tweetfancy.io

2018 - Year In Review

Things I built in 2018

Things I wrote in 2018

Goal Stats

Summary

Dev principles I picked up in 2018

2018: Year In Review

What is the role of a developer advocate?

Generate a `meta.json` file with the app version on each build

Fetch `meta.json` on load and compare versions