DEV Community: Dhaiwat Pandya

How I stay productive

Dhaiwat Pandya — Fri, 20 Aug 2021 13:11:14 +0000

You read the title. Let's get straight into it.

(This is not advice.)

I don't try to be productive all the time

Trying to be productive all the time is not practical. No one can be productive all the time. We aren't machines. We are subject to ups and downs in our energy levels and motivation. We all need to 'go slow' every once in a while. I don't feel bad about it. It is perfectly normal.

I like to think of life as a marathon, rather than a sprint. The slow and the steady wins the race. I like to slow down, recharge and go for it again — rather than constantly trying hard and inevitably burning out.

Breaks

Timely breaks are a game-changer. When I feel like I've hit a dead-end, I take a short break and come back to the problem later. I usually come back with a completely different set of ideas & make the problem easier. The break could be a short walk (the best!), reading a book, listening to a podcast, a game of Warzone — anything!

Changing things up is the key. I need something that takes my mind away from the problem and gives it some time to relax. I am often surprised by the wonders our brains can do when we approach problems differently.

Lifestyle over 'rapid growth'

When I first started out as a developer in the industry, I used to say yes to every opportunity in my reach. Over the years, I have learnt to say no.

Sure, saying yes to every other project that comes my away would make me a lot of money — but at what cost? I used to spend my entire day working on low-quality projects. Even though I was making more money, the pleasure was short-lived. My inner self used to feel disappointed with myself. I wasn't treating myself like I knew I should. At one point, I flicked the switch.

I started only taking on projects that allowed me to grow & had a great work environment — even if that meant that I would be making a less money, at least temporarily.

In the long term, this has allowed me to make much more money. 😉 This is why I hold the opinion that too much speed is bad. When it feels like too much is happening at the same time, I slow down. I take a deep breath, re-assess and say no to some things.

I choose, and will continue to choose, lifestyle over 'rapid career growth'.

Intrinsic motivation

I have desired traveling the world ever since I was a kid. There is lots to do on our beautiful planet — mysterious places to visit, awesome people to meet and tasty food to enjoy!

But I come from a humble background. I have never stepped foot outside of India. I need a lot of money for that. I knew could earn a lot of money by being a good software developer. Coincidentally, I happened to fall in love with computers as a 5-year-old kid. A match made in heaven.

The dream of going to all those places I've always wanted to see is what keeps me going. I'm not quite there yet, but I will be. One day.

I utilize procrastination

Utilizing procrastination? Doesn't make a lot of sense. Let me explain.

Whenever I find myself procrastinating, I don't fight it. I use it as information. I think — 'If I really wanted to do it, I would have jumped into action already. I wouldn't wait. Nothing would stop me.' As Daniel Vassallo would say, procrastination helps me avoid things that don't give me energy. It can't tell me what I should do, but it can tell what I shouldn't do. Whenever I can afford to, I try to use this information to guide myself.

Embracing procrastination rather than fighting it has changed my life for the better.

I try to help

I am really grateful for the tech community — be it on Twitter, Hashnode, DEV or anywhere else. I am forever in debt of some folks from the community who held my hand when I was a newbie. I owe so much.

This is why I try to give back whenever I can. Most of my contributions come in the form of open source contributions & articles. How does this help me in being productive? It gives me inner peace, reduces stress. I feel proud of the person I see when I look in the mirror. This might not make any difference for some people but it impacts my life drastically. It just works.

'Happiness is only real when shared'
— Christopher McCandless

Parting remarks

Like I mentioned earlier, please do not consider this as advice. No 'advice' is ever universal. What works for me might not work for you. These are my experiences and I tried to share them from a very personal point of view.

If you found my insights interesting, consider following me on Twitter.

Cover photo by Murray Campbell.

Become a better writer as a developer

Dhaiwat Pandya — Tue, 27 Jul 2021 21:34:51 +0000

Writing is an excellent way to improve your reputation as a developer. You can build an audience from scratch, become more employable and, of course, get better at writing! Here are some tips which will hopefully help you improve:

Pick one idea and stick to it 💪

It is important that you don't wander around in your thoughts. Decide on a pivotal idea and construct your piece around it. If you get lost, the reader will too.

Stick to your guns.

Don't worry about running out of content. Set the theme for the reader at the beginning of your article - plant a seed in their mind. Then, approach your idea through different examples, different pathways. Keep circling back to it - grow the seed you planted.

Give your reader a trip around your mind ✈️ (and make it interesting! 😎)

Writing is about freeing your thoughts. When going through your article, a reader should get a feeling of the author's thought process.

Your readers should feel what you feel about the idea. They should understand why it is important you.

^ And you have to make all of that interesting for your readers. Let's be honest, no one wants to read a boring, monotonous piece. Make it fun, come on! Add some analogies. Share your anecdotes. Sprinkle some humour. It goes a long way!

Write as if you were having a conversation 🙌

Balancing your writing between too serious and too corny can be difficult. A good heuristic is to imagine having a conversation with the reader, and writing exactly what you would say. I picked this up from a writer that I look up to. I've never looked back.

If you sound friendly, your reader will trust you. You absolutely want your readers to trust you. We love hearing from people we can relate to.

Be the person that your readers can relate to.

Edit ruthlessly 😤

Treat writing and editing differently.

When you are writing, treat yourself like a baby - very extremely nurturing and loving. Write down anything and everything that comes to your mind. Do it freely.

When you are editing, switch over to Mr. Fletcher from Whiplash and just be a harsh, ball-busting prick. Remove anything that is even slightly pointless. Convey as much as possible, using as little as possible.

The point of editing is creating a straight line out of a knot. You will be surprised by how much unnecessary things you were able to cut from your writing. Being good at editing is one of the most important skills you can have as a writer - and I really cannot stress this enough.

Write drunk. Edit sober.
— Ernest Hemingway

Read & follow good writers 👏

Reading is like breathing in. Writing is like breathing out.

Look up to the people who know their craft well. (Following me might be a good place to start 😝)

Rigorously study your favorite writers' work. Try to understand why & how they do what they do. Study how they explain their code. Analyze how they plant the 'seed' in your mind and how they grow it.

Take good things from the people you study & put them to use in your work. Don't feel bad for taking inspiration or being unoriginal. Like a wise man said - 'Great artists steal.'

Become great at stealing.

Don't explain every line of your code 👎

Try to limit the amount of code you share in your article. Only talk about the piece of code that is 100% relevant to the theme. Please, please don't explain things which are trivial and which you expect your readers to know. Respect your readers. An article explaining what a console.log does is an instant turn-off.

You can always upload your entire codebase to a Github repo and provide that as a supplement to your readers.

Write 🤷‍♂️

Last, but not in any way the least — write. A lot.

At times, you will feel uninspired, but gotta keep writing. It is, of course, okay to take breaks. They can work wonders for you, but it is equally important to be persistent. The water does not flow until the faucet is turned on. Have the courage to start. The rest will follow. I promise.

Once you start writing, you will start picking up on tiny things like how to effectively use pauses, how to set the rhythm for your paragraphs, etc. These things cannot be taught. You will notice them coming your way as you write. Pay attention to them because these small details make all the difference.

Conclusion ✍️

That's all I had in store for you today. I am myself in the middle of my learning journey, so please consider all of this my experience rather than advice. I'm just sharing what I know!

If this article helped you, consider dropping a follow and a kind comment. I read every single one of them. They make my day. (seriously!)

Cover photo by Lukas Blazek.

Understanding React Testing Library

Dhaiwat Pandya — Mon, 12 Jul 2021 15:04:03 +0000

Who doesn't love React Testing Library? If you write tests for React, you probably use it a lot. People even like to call it the successor of Enzyme, but React Testing Library and Enzyme are nothing alike. While React Testing Library already gives you superpowers — understanding its principles will help you write much better tests for your React UIs. I promise you will gain something out of this short read.

The idea & the principles

The user lives in the heart of the principles of React Testing Library. Everything that the library does, revolves around the user.

Good UI tests give you confidence that your components work for your users. They verify that your components look right and behave the right way. How you implement it behind the scenes is not important for the user. This is why good UI tests should never rely on the implementation details of a UI component.

If your tests rely on how a given component is implemented, those test cases will break when you re-factor your codebase. This makes your tests extremely hard to maintain and will slow you down. You don't want that.

Remember — you want your UI tests to verify the end result, not the internal implementation. This is the pivotal idea behind React Testing Library.

The more your tests resemble the way your software is used, the more confidence they can give you.

— testing-library.com

Enzyme gives you access to the component's state, props, children, etc. React Testing Library doesn't do that. It gives you the DOM instead because that's what your users will have. If your tests are good enough, you will never have to explicitly access the component's state or props to make any assertions. Just use the DOM.

Passing a backgroundColor prop to a <Button />? Render the button to the DOM and verify that the rendered button's background color. Don't access the props of the component and make an assertion. Make a visual assertion.

it('should apply the background color properly', async () => {
    const bgColor = '#ccc222';
    const text= 'hi';
    const { getByText} = render(<Button backgroundColor={bgColor} text={text} />);
    const button = getByText(text);

    expect(button.style.backgroundColor).toEqual(bgColor);
})

Want to test the loading state of a component? Make an assertion on the way the component looks when it is loading. Don't verify whether the loading state of the component is true.

it('should render correctly while loading', async () => {
    const src= '#';
    const altText = 'hi';
    const { getByAltText } = render(<Image src={src} alt={altText} />);
    const image = getByAltText(altText);
    expect(image.src).toEqual(loadingSrc);
    // Note: you need to write fireEvent.load(image) in order to complete loading the image.
    // Since we have not done that, the image is still 'loading'.
})

The benefits

React Testing Library is inspired by its love for great user experience. If you are writing good tests using React Testing Library, you can be assured that the experience you ship to your users will be what you wanted. It gives you that much-needed confidence when pushing to production and let me tell you, it feels good. Anything that relieves you of some stress is a blessing and React Testing Library is definitely one.

What about the developer experience? Well, React Testing Library excels at that, too. The syntax is extremely intuitive. You don't have to know any intricacies in order to get up and running. The querying methods like getByText, getByAltText, etc allow developers to query the DOM just like a real end-user. This is so important.

Another massive benefit this library offers to developers is that as long as you only re-factor your component's implementation (not functionality), your tests will not break. I might be repeating myself here, but this will save you a lot of time & headaches. And you will absolutely love it when you refactor the code and nothing breaks. Trust me.

Oh, and the documentation is everything a developer would want from a library. It's perfect.

Conclusion

All in all, React Testing Library helps you ship UIs which are optimized for your end-users. This is something no developer/team would say no to.

I listed a lot of pros of using the library here but if you think there are any cons, comment down below. Let's discuss!

If you gained anything from this article, please follow me here on DEV & on Twitter. I try to balance my Twitter content between knowledge & shitposts. I can promise you will not be disappointed!

References & resources

testing-library.com
testingjavascript.com
Kent C Dodds (The author of this library - the MVP!)
Cover image by Weiqi Xiong

A magical way to fetch data in React

Dhaiwat Pandya — Mon, 28 Jun 2021 12:07:51 +0000

If you have ever used React, chances are that you have had to query an API. The importance of data fetching in a website is indispensable. To build a truly delightful experience, you must get your data fetching right. It is critical.

Let me quickly run you through the traditional approach for querying in React applications. Most of this might seem trivial to you, but it is important that we go through it to see the difference react-query really makes. (it's magic, trust me😉)

We will use the JSON Placeholder API as our source of data. We will primarily be making two types of queries: a list of all posts and an individual post. Let's write a hook to fetch the list of all posts.

const baseUrl = 'https://jsonplaceholder.typicode.com';

const usePosts = () => {
  const [data, setData] = useState();

  useEffect(() => {
    const fetchData = async () => {
      const res = await fetch(`${baseUrl}/posts`);
      const posts = await res.json();
      setData(posts);
    };
    fetchData();
  }, []);

  return { data };
};

This should look familiar. You'll notice that we have not handled errors or the loading state. That's bad practice. Let's do that now.

const usePosts = () => {
  const [data, setData] = useState();
  const [isLoading, setLoading] = useState(true);
  const [error, setError] = useState();

  useEffect(() => {
    const fetchData = async () => {
      setLoading(true);

      try {
        const res = await fetch(`${baseUrl}/posts`);
        const posts = await res.json();
        setData(posts);
        setLoading(false);
      } catch (error) {
        console.log(error);
        setError(error);
        setData([]);
        setLoading(false);
      }
    };

    fetchData();
  }, []);

  return { data, isLoading, error };
};

Woah... that certainly was not pleasant. 😒 We had to add a ton of code just to make our hook support two simple states. And this query runs... basically every time your component re-renders? This is far from ideal. You deserve better.

What about background updates? Stale data? Pagination? Programatically re-running queries?

Good luck with all that. 🤷‍♂️

This is where react-query comes to your rescue. Use this repo as boilerplate if you want to follow along.

Let's now re-factor our usePosts hook using react-query. If you haven't used react-query before, you're in for a surprise.

// hooks/hooks.js
const usePosts = () => {
  const fetchData = async () => {
    return fetch(`${baseUrl}/posts`).then((r) => r.json());
  };

  return useQuery('posts', fetchData);
};

Yeah. That's it. I told you. 😎

The same can be done for the usePost hook.

const usePost = (id) => {
  const fetchData = async () => {
    return fetch(`${baseUrl}/posts/${id}`).then((r) => r.json());
  };

  return useQuery(['post', id], fetchData);
};

This piece of code is all you need to handle everything we handled with the traditional approach — and we're barely scratching the surface. Let's dive deeper.

Open the react-query devtools by clicking the icon shown in the screenshot below. Keep it open.

Click around the web-app now and keep an eye out on the devtools. You will notice queries being logged as they are executed. It is pretty intuitive.

I mentioned that react-query can do much more than just manage states like loading, error, etc. Let me walk you through one of those things — query invalidation. In simple words, query invalidation is you telling react-query to consider the respective query 'stale', and re-run the query. Let's try it out.

We will be adding a re-fetch button at the top of our list of posts. Needless to say, clicking this button should make our app re-fetch the list of posts. Since we are using react-query for this, this is going to be a piece of cake for us. 😁

// pages/index.js
import { useQueryClient } from 'react-query';

export default function Home() {
  const queryClient = useQueryClient();

  const reFetchPosts = () => {
    queryClient.invalidateQueries('posts');
  };

  return (
    <Container>
      <Button onClick={reFetchPosts}>Re-fetch</Button>
      {data.map((post) => {
        //...
      })}
    </Container>
  );
}

That is all we need to add. Now try clicking our newly added re-fetch button and keep an eye out on the react-query devtools. You will notice that it re-runs the query as expected. You can also verify this by making use of the Network tab in your browser's devtools.

In conclusion, we took 27 lines of code, narrowed it down to merely 7 lines, and ended up with more functionalities to work with. That sounds like a good deal to me. 🤝

Staggering. I promised it is magical. 😊

If you like this article, please follow me here and on Twitter. I mostly tweet rants about software & brag about my tiny wins. ⚡

Please feel free to comment down below to start discussions or ask questions. I will happily answer them. 🤗

References:

Official react-query docs

All About React Query (with Tanner Linsley) — Learn With Jason

React Query - Data Fetching Hooks — Leigh Halliday

Cover photo by Simon Berger

Develop & test React components in isolation

Dhaiwat Pandya — Mon, 21 Jun 2021 03:28:57 +0000

Writing front-end code is easy. But writing reliable front-end code? That's tough.

Modern UIs are more complicated than ever. It is critical that you have confidence in your code. Developing and testing your UI components in isolation allows you to accomplish that.

In this article, we will go through the process of crafting an isolated, independent & reliable Image component for React. We will be leveraging tools like Storybook, Testing Library and Jest. ✨

To follow along, use this repo as boilerplate.

After installing the dependenices, run yarn storybook to start the Storybook and run yarn test --watch to start the test-runner.

Let's start with tests.

Writing tests before you start developing your component is important. We want our component to fulfill our test cases. Not the other way round. Tests give you constant feedback during development. Once you pass all the tests, you can be assured that your code will work as intended.

There is one thing that you have to keep in mind, though. Since your code's quality is being verified by the tests you write, it is critical that you write good tests. A good unit test should be readable, fast, reliable and should cover all the different use cases of your component.

Let's write the test cases now.

// src/components/Image/Image.test.tsx
import * as React from 'react';
import { fireEvent, render } from '@testing-library/react';

import { Image } from './';
import { photoSrc } from '../../constants';

const altText = 'abcd';

describe('Image', () => {
  it('should render the image properly', async () => {
    // render the Image component
    const { getByAltText } = render(<Image src={photoSrc} alt={altText} />);

    // retrieve a reference to the image
    const image = getByAltText(altText) as HTMLImageElement;

    // load the image
    fireEvent.load(image);

    // verify that the image exists on the DOM
    expect(image).toBeTruthy();

    // verify the src of the image
    expect(image.src).toEqual(photoSrc);
  });
});

The test will, of course, not pass. We still haven't written the mark-up for our component. Let's do that now.

// src/components/Image/index.tsx
import React from 'react';
// import { fallbackSrc, loadingSrc } from '../../constants';

export interface ImageProps {
  src: string;
  alt: string;
  height?: string | number;
}

export const Image: React.FC<ImageProps> = ({ src, alt, height = '400px' }) => {
  return (
    <>
      <img
        src={src}
        alt={alt}
        style={{ height, width: 'auto', borderRadius: '10px' }}
      />
    </>
  );
};

You will notice that the test now passes. ✔️ Awesome! (If you get an error, restart the test runner.)

Wait...but what does our component look like? Should we render it on the home route of our React app? 🤔

No. We will leverage Storybook for this.

Let's write the Story for our component.

A story captures the rendered state of a component. We write multiple stories per component that describe different states a component can support. Stories allow us to develop React components in isolation. If you are not familiar with Storybook, I highly recommend that you go through this page.

// src/components/Image.stories.tsx
import React from 'react';
import { Story, Meta } from '@storybook/react';

import { Image, ImageProps } from './';
import { photoSrc } from '../../constants';

export default {
  title: 'Example/Image',
  component: Image,
  argTypes: {
    src: { control: 'text' },
    alt: { control: 'text' }
  }
} as Meta;

const Template: Story<ImageProps> = args => <Image {...args} />;

export const Primary = Template.bind({});
Primary.args = {
  src: photoSrc,
  alt: 'Sample alt text'
};

There it is! Our Image component is looking clean. But right now, it does not handle the loading state and errors properly. Let's write tests for these two cases. Replace your test file code with the following:

// src/Image/Image.test.tsx
import * as React from 'react';
import { fireEvent, render } from '@testing-library/react';

import { Image } from './';
import { fallbackSrc, loadingSrc, photoSrc } from '../../constants';

const altText = 'abcd';

describe('Image', () => {
  it('should render the image properly', async () => {
    // render the Image component
    const { getByAltText } = render(<Image src={photoSrc} alt={altText} />);

    // retrieve a reference to the image
    const image = getByAltText(altText) as HTMLImageElement;

    // load the image
    fireEvent.load(image);

    // verify that the image exists on the DOM
    expect(image).toBeTruthy();

    // verify the src of the image
    expect(image.src).toEqual(photoSrc);
  });

  it('should display the loader until the image loads', async () => {
    const { getByAltText } = render(<Image src={photoSrc} alt={altText} />);

    const image = getByAltText(altText) as HTMLImageElement;

    // verify that the src of the image matches the loader. note that the image has not been loaded yet.
    expect(image.src).toEqual(loadingSrc);
  });

  it('should handle errors and render the fallback', async () => {
    const { getByAltText } = render(<Image src="#" alt={altText} />);

    const image = getByAltText(altText) as HTMLImageElement;

    // fire the error event for the image
    fireEvent.error(image);

    // verify that the src of the image matches our fallback
    expect(image.src).toEqual(fallbackSrc);
  });

  // an extra test case that verifies that our height prop behaves as expected
  it('should apply the provided height', async () => {
    const height = '200px';
    const { getByAltText } = render(
      <Image src={photoSrc} alt={altText} height={height} />
    );

    const image = getByAltText(altText) as HTMLImageElement;

    fireEvent.load(image);

    expect(image.style.height).toEqual(height);
  });
});

We also added an extra test case for the height prop. More (good 😉) test cases never hurt!

Two out of the three newly added tests will indeed fail. Let's re-visit the code for our component and change it so that our tests pass. Modify your component's source code to match the following:

// src/components/Image/index.tsx
import React from 'react';
import { fallbackSrc, loadingSrc } from '../../constants';

export interface ImageProps {
  src: string;
  alt: string;
  height?: string | number;
}

export const Image: React.FC<ImageProps> = ({ src, alt, height = '400px' }) => {
  // whether an error has occured or not
  const [err, setErr] = React.useState(false);

  // whether the image is loading or not
  const [loading, setLoading] = React.useState(true);

  return (
    <>
      <img
        // use the fallback image as src if an error has occured
        // use the loader image as src if the image is still loading
        src={!err ? (loading ? loadingSrc : src) : fallbackSrc}
        alt={alt}
        style={{ height, width: 'auto', borderRadius: '10px' }}
        // set loading to false once the image has finished loading
        onLoad={() => setLoading(false)}
        // set err to true if an error occurs
        onError={() => setErr(true)}
      />
    </>
  );
};

The code may seem daunting at first, but it isn't complicated. We are using state to keep track of two things - whether the image is still loading, and whether an error has occured. Then, we leverage these state variables to conditionally render the image with the appropriate src. It's that simple!

Let's now write a Story to see our fallback image in action. Add the following code to the bottom of your component's .stories file.

export const Src404 = Template.bind({});
Src404.args = {
  src: '#',
  alt: 'something broke'
};

And just like that, we added a new Story (a rather sad one) for our component. You can easily switch between your component's states to see how your component behaves. This is the power of Storybook!

You will also notice that all the test cases now pass! 🥳 Aren't those green ticks just lovely?

That's it. We have now successfully developed a reliable React component in isolation.

You must be feeling confident about the code that you just wrote. Doesn't that feel great? 🤩

😇 If this article helped you, follow me on Twitter. I won't disappoint you. I promise.

💡 If you're feeling curious, go visit componentdriven.org to learn more about the Component-Driven Development process.