DEV Community: Avi Aryan

What do I learn today to get a dev job?

Avi Aryan — Thu, 21 May 2020 07:52:52 +0000

What do I learn today to get a dev job?

Believe it or not, JavaScript and React are still the first things I would learn if I was starting from scratch.

One could say - “JS and React have had a BOOM period for some time. They will come back to the ground soon.”

But that’s not true. Both JS and React ecosystems keep on innovating.

Recently, Microsoft launched React Native for MacOS.

This might change the field of MacOS development, and a good chunk of Swift or Electron apps will be written in React Native.

The React team recently launched Suspense and before that Hooks which are game-changers in UI development.

JS is not behind too. Both the ECMA and the Node team keep on releasing new versions and specifications regularly.

Recently Deno launched which is a new runtime for JS and TS.

Also, the wide-adoption of TypeScript is helping JavaScript “haters”, programmers that despise loose-typing (Java, C#, Go programmers) to use JavaScript.

Overall, the future of React and JS looks bright for at least the next 3 years, if not more.

So you can confidently start or change your career on this stack.

This article was first posted on my blog.

How to start contributing to open-source for experienced devs

Avi Aryan — Fri, 15 May 2020 10:08:18 +0000

I got this question in my DM yesterday so here’s how I do it.

(1) Contribute to something you use.

If you have been a dev for some time, chances are you are using many things open source. Eg - youtube-dl, NextJS, ReactJS, Prettier.

Even things that are not open source can have open-source components. Eg - Firebase.

Deciding to contribute to something you use ensures you have the background knowledge and the motivation to do the contribution.

An open-source contribution is a challenging process so this is important.

(2) Look into issues, pick one that excites you

Popular projects have tons of issues. Pick one that you understand and think you can do.

Don’t be ashamed if it’s an easy issue. All contributions matter.

(3) Clone the codebase, understand it and then do the fix

Don’t worry if understanding the codebase takes time. It is expected to take time.

(4) Finally, send a PR

Your PR may not get merged in a day or two. This is normal.

Project maintainers are busy and have a backlog of PRs.

Gently remind them after a week.

Follow through their feedback, and soon you will have your PR merged.

This was first posted on my LinkedIn.

Why you should do ethical hacking anyway?

Avi Aryan — Sun, 05 Apr 2020 10:33:52 +0000

I was looking into ethical hacking as I was interested in CyberSec and was looking for a practical way to get in.

After some reading and playing around, I see its potential.

It’s a great field to apply concepts from various domains of software development.

Here is what I had to use in only 2 days of doing ethical hacking on HackThisSite.

HTML
JavaScript
HTTP (Protocol Knowledge)
Backend
Common Software Development Patterns
SQL
Web servers (Apache, Nginx)
Thinking like a Notorious Hacker
Street Smarts

As you can see, ethical hacking requires using knowledge from various spectrum of software development to get work done.

In other words, it’s extremely practical.

I would recommend everyone to try it.

Google “OWASP Top 10” and learn the concepts mentioned there.
Then, create an account on HackThisSite(dot)org and try solving the challenges.

Rendering JSON-LD data in NextJS and ReactJS

Avi Aryan — Thu, 05 Mar 2020 12:28:03 +0000

Rendering JSON-LD data in NextJS and ReactJS is quite straight-forward. Here are the steps involved.

Organize data in a plain JavaScript Object.
Serialize it using JSON.stringify.
Include the data in the script tag using dangerouslySetInnerHTML.
Optional but recommended - Attach a key.

The first step is creating the JSON Object. I used this in GoRemote which is a job-listing site. Here is the function which creates a job schema given the job object. It returns a simple JavaScript object.

function makeJobSchema(job) {
    const desc = stripHTML(job.description)
    return {
        // schema truncated for brevity
        '@context': 'http://schema.org',
        '@type': 'JobPosting',
        datePosted: job.postedAt,
        description: desc,
        title: job.title,
        image: job.company.logo,
        workHours: 'Flexible',
        validThrough: addDaysToDate(job.postedAt, 60),
        hiringOrganization: {
            '@type': 'Organization',
            name: job.company.name,
            sameAs: job.company.website || null,
            logo: job.company.logo,
        },
    }
}

The next step is to serialize this object using JSON.stringify. Once serialized, we insert it in a script tag using dangerouslySetInnerHTML. Here is how the code looks like.

export default function JobSchema({ job }) {
    return (
        <script
            key={`jobJSON-${job.id}`}
            type='application/ld+json'
            dangerouslySetInnerHTML={{ __html: JSON.stringify(makeJobSchema(job)) }}
        />
    )
}

Now, you might question, why do we use dangerouslySetInnerHTML? Why not insert the serialized object as a string? Because if we do that, React treats it as HTML and so HTML-escapes the text. The output then looks like this.

<script type="application/ld+json">
    {&quot;@context&quot;:&quot;http:...
</script>

This won’t work with bots that will crawl the page for this metadata. In other words, we don’t want to HTML-escape the text within these script tags. So, that’s why we use dangerouslySetInnerHTML.

Another question would be why do you need to add a key? It’s not needed but it’s a good-to-have to avoid the situation where you have multiple JSON-LD’s for a single entity. A key makes sure that only one such instance is included in the rendered page.

Well, there you have it.

Once you have the page running, you can use ngrok to expose your localhost online and Google’s structured data testing tool to make sure everything works as expected.

This article was posted on Avi Aryan's Blog.

Practical Software Testing Ideas

Avi Aryan — Tue, 25 Feb 2020 07:26:45 +0000

Testing is one of the most important practices in software development. And with automated test runners like Travis, there’s no reason not to write tests.

In this article, I talk about the testing ideas that have helped me in my developer life.

Test external dependencies periodically

External APIs can break anytime. They don’t actually "break" but the API you expect it to provide and the API it provides can mismatch anytime. So, you can’t relax while using them.

One way to reduce this risk is by running tests against them periodically. You can use the cron feature of TravisCI to do so. For example, in GoRemote, I use these tests to make sure that StackOverflow doesn’t “break for me”.

Test close negative cases as well

Many developers only test the positive cases of a test. That is, this should work like that. But they should test the negative cases as well. This is especially true when it's quite easy for the tested function to be buggy.

function hasUnicodeOne(string) {
    return string.match(/¹1️⃣/)
}

test('', () => {
    expect(hasUnicodeOne('¹')).toBe(true)
    // negative test case below
    expect(hasUnicodeOne('1')).toBe(false)
})

There’s a chance the above function includes numeric 1 in the regex. So we test the negative case for it to make sure it doesn’t happen.

When in doubt, test

Many times you won’t be sure if you want to test that code or not. It might be too trivial. Or you would think you don’t need to check it because it would never happen. In that case, write the test. Writing tests never did any harm.

Backend tests > Frontend tests, usually

Backend tests are usually more important than frontend tests. More so if backend handles all the data manipulation. So make sure to test the backend. If you have limited time to give on tests, prefer backend.

Yes, I know that we should test everything. But when working on a tight schedule, it can be challenging to justify time writing less critical tests. So this is what you do then.

Don’t delete or comment a test

At times, you might want to delete a test because it isn’t adding value. Or a test failed and you think you don’t need it and so you comment it out. Don’t do that, ever. This starts the bad habit of commenting or removing tests and after a while, your code is left untested. Instead, take the time and fix the test.

Don’t leave your project with failing builds

Don’t leave your project with failing tests. It doesn’t matter if the test that is failing is non-critical. Fix it! Now. Otherwise, it will envelop a critical failing test later on. And you won’t know because you will think that it’s the non-critical test that is causing the build to fail.

Try to practice TDD

I recommend TDD. But I know it’s hard to follow when working on a deadline, trying to ship that feature. So yeah, try to do it. But if not, still okay.

Many a time, I don’t do TDD because I don’t need to run the tests every time to check. I know that the new test will fail and adding this optimized logic to the code will fix it. So I write the finished code and test only in the end instead of testing three times — one fail, one pass, one refactor.

Use tests as you use insurance

You have insurance for your health, life, and house. Tests are the same. They are insurance for your code. Also, insurance costs money in real life. But software tests usually don’t cost anything. So use it.

You can say writing tests take time but it prevents you from getting on that Saturday evening call because of a critical bug discovered in production. So I will say the time spent is worth it.

And it saves money as well since you will lose business if your product is buggy. So, writing tests is value for time and money spent.

Prefer integration tests over unit tests, when in a bind

Many times, you don’t have the time to test everything. Or you don’t want to. Whatever it is, in that case, prefer integration tests over unit tests. By their nature, they cover a larger surface area of the code. So they have more chance of finding a non-trivial bug. Note that they won’t find all the bugs in your code. Only the outstanding ones.

Don’t test like a robot

Testing is as much art as science. You need to know what to test.

Trying to reach 100% coverage will take a lot of time and you may still leave bugs if you don’t know what to test.

So chill out, put on your creative hat, and write tests that can catch bugs. One way to do this is by starting to notice where you discover bugs in software applications and writing tests to capture those.

First posted on my blog

Why you should get a good, international domain for yourself

Avi Aryan — Fri, 14 Feb 2020 14:23:44 +0000

I see many new developers and even some senior developers going by a .in or even a .tk for their websites.

But this is short-sighted. Why?

Because you might move out of India. Or you might work for US and UK companies remotely. In that case, .in is not the ideal TLD you want for your domain. And .tk is not even worth a mention. It’s available for free and it doesn’t make a good impression of you.

Get a .com if possible. If your name is too common, get a .io or .tech or .co or .net. Anything less than that is selling yourself short.

Saving $7/year by getting a .in instead of a .com might look like a deal when you are starting as a developer but after a few years, you will regret saving $28 by not getting a .com.

So do it right whilst you still have time (SEO!) and get a proper domain.

Otherwise, you will be like me, renewing your .in domain every year (aviaryan.in) till the end of the universe so that you can permanently redirect its traffic to your .com domain.

This article was first posted to my newsletter.

Immutable requirements if you want a remote job

Avi Aryan — Mon, 03 Feb 2020 10:57:28 +0000

I see many people want to do remote jobs. But in my experience, there are some things that you need before you can have a great remote work career.

Consider it as the smallest definite checklist.

Note that these might be true for office jobs as well but there, the requirements are relaxed.

For example - You can do well even if your communication skills are poor. You might get promoted as well. But having bad communication skills will make it impossible to work remotely.

Good communication

You need to communicate well. If you can’t speak English (or your team’s language), that’s an issue.

Remote work features both spoken and written communication. And you need to be decent at both since confusion or lack of clarity can be harmful to your team.

Self-Starter

If your team is in different timezones, often you will be at a spot where you don’t know what to do next and your manager will not be online to tell you.

Or you just came across an unexpected situation and you will have no one to discuss with. In that case, you need to be able to weigh the choices and make the best decision for the team so that you utilize your time.

Okay with some timezone overlap

You will need to do some timezone overlap to work remotely if your team is across the globe.

A 100% overlap isn't required but there will be meetings and scrum calls and you need to be ready for that.

Your timezone shouldn’t cause problems for the team.

Quality work

In remote work, mentorship is scarce. Or not the same as you would get in an office job. So you need to be able to deliver good work.

Work that gets accepted in the first shot or doesn’t need much to-and-fro. Because, to-and-fro wastes even more time in a remote setting where members live in different, sometimes opposite timezones.

Also, failing reflects badly in remote work. This is because, in an office job, your manager can see that you did the work or at least tried. But in a remote job, it can be assumed that you didn’t do the work or slacked off.

If you identify yourself with each of the points mentioned above, consider yourself ready for remote work.

If not, work on them.

PS - I am working on a remote jobs list for India. It has 300+ tech remote jobs available in the Indian timezone. Check it out. GoRemote

This article was first posted to my newsletter.

A guide to stale-while-revalidate data fetching with React Hooks

Avi Aryan — Mon, 03 Feb 2020 10:54:44 +0000

Leveraging the stale-while-revalidate HTTP Cache-Control extension is a popular technique. It involves using cached (stale) assets if they are found in the cache, and then revalidating the cache and updating it with a newer version of the asset if needed. Hence the name stale-while-revalidate.

How stale-while-revalidate Works

When a request is sent for the first time, it's cached by the browser. Then, when the same request is sent a second time, the cache is checked first. If the cache of that request is available and valid, the cache is returned as the response. Then, the cache is checked for staleness and is updated if found stale. The staleness of a cache is determined by the max-age value present in the Cache-Control header along with stale-while-revalidate.

This allows for fast page loads, as cached assets are no longer in the critical path. They are loaded instantly. Also, since developers control how often the cache is used and updated, they can prevent browsers from showing overly outdated data to users.

Readers might be thinking that, if they can have the server use certain headers in its responses and let the browser take it from there, then what's the need of using React and Hooks for caching?

It turns out the server-and-browser approach only works well when we want to cache static content. What about using stale-while-revalidate for a dynamic API? It's hard to come up with good values for max-age and stale-while-revalidate in that case. Often, invalidating the cache and fetching a fresh response every time a request is sent will be the best option. This effectively means no caching at all. But with React and Hooks, we can do better.

stale-while-revalidate for the API

We noticed that HTTP's stale-while-revalidate doesn't work well with dynamic requests like API calls.

Even if we do end up using it, the browser will return either the cache or the fresh response, not both. This doesn't go well with an API request since we would like fresh responses every time a request is sent. However, waiting for fresh responses delays meaningful usability of the app.

So what do we do?

We implement a custom caching mechanism. Within that, we figure out a way to return both the cache and the fresh response. In the UI, the cached response is replaced with a fresh response when it's available. This is how the logic would look:

When a request is sent to the API server endpoint for the first time, cache the response and then return it.
The next time that same API request happens, use the cached response immediately.
Then, send the request asynchronously to fetch a new response. When the response arrives, asynchronously propagate changes to the UI and update the cache.

This approach allows for instantaneous UI updates---because every API request is cached---but also eventual correctness in the UI since fresh response data is displayed as soon as it's available.

In this tutorial, we will see a step-by-step approach on how to implement this. We will call this approach stale-while-refresh since the UI is actually refreshed when it gets the fresh response.

Preparations: The API

To kickstart this tutorial, we will first need an API where we fetch data from. Luckily, there are a ton of mock API services available. For this tutorial, we will be using reqres.in.

The data we fetch is a list of users with a page query parameter. This is how the fetching code looks:

fetch("https://reqres.in/api/users?page=2")
  .then(res => res.json())
  .then(json => {
    console.log(json);
  });

Running this code gives us the following output. Here is a non-repetitive version of it:

{
  page: 2,
  per_page: 6,
  total: 12,
  total_pages: 2,
  data: [
    {
      id: 7,
      email: "michael.lawson@reqres.in",
      first_name: "Michael",
      last_name: "Lawson",
      avatar:
        "https://s3.amazonaws.com/uifaces/faces/twitter/follettkyle/128.jpg"
    },
    // 5 more items
  ]
}

You can see that this is like a real API. We have pagination in the response. The page query parameter is responsible for changing the page, and we have a total of two pages in the dataset.

Using the API in a React App

Let's see how we use the API in a React App. Once we know how to do it, we will figure out the caching part. We will be using a class to create our component. Here is the code:

import React from "react";
import PropTypes from "prop-types";

export default class Component extends React.Component {
  state = { users: [] };

  componentDidMount() {
    this.load();
  }

  load() {
    fetch(`https://reqres.in/api/users?page=${this.props.page}`)
      .then(res => res.json())
      .then(json => {
        this.setState({ users: json.data });
      });
  }

  componentDidUpdate(prevProps) {
    if (prevProps.page !== this.props.page) {
      this.load();
    }
  }

  render() {
    const users = this.state.users.map(user => (
      <p key={user.id}>
        <img
          src={user.avatar}
          alt={user.first_name}
          style={{ height: 24, width: 24 }}
        />
        {user.first_name} {user.last_name}
      </p>
    ));
    return <div>{users}</div>;
  }
}

Component.propTypes = {
  page: PropTypes.number.isRequired
};

Notice that we are getting the page value via props, as it often happens in real-world applications. Also, we have a componentDidUpdate function, which refetches the API data every time this.props.page changes.

At this point, it shows a list of six users because the API returns six items per page:

Adding Stale-while-refresh Caching

If we want to add stale-while-refresh caching to this, we need to update our app logic to:

Cache a request's response uniquely after it is fetched for the first time.
Return the cached response instantly if a request's cache is found. Then, send the request and return the fresh response asynchronously. Also, cache this response for the next time.

We can do this by having a global CACHE object that stores the cache uniquely. For uniqueness, we can use this.props.page value as a key in our CACHE object. Then, we simply code the algorithm mentioned above.

import apiFetch from "./apiFetch";

const CACHE = {};

export default class Component extends React.Component {
  state = { users: [] };

  componentDidMount() {
    this.load();
  }

  load() {
    if (CACHE[this.props.page] !== undefined) {
      this.setState({ users: CACHE[this.props.page] });
    }
    apiFetch(`https://reqres.in/api/users?page=${this.props.page}`).then(
      json => {
        CACHE[this.props.page] = json.data;
        this.setState({ users: json.data });
      }
    );
  }

  componentDidUpdate(prevProps) {
    if (prevProps.page !== this.props.page) {
      this.load();
    }
  }

  render() {
    // same render code as above
  }
}

Since the cache is returned as soon as it is found and since the new response data is returned by setState as well, this means we have seamless UI updates and no more waiting time on the app from the second request onward. This is perfect, and it is the stale-while-refresh method in a nutshell.

The apiFetch function here is nothing but a wrapper over fetch so that we can see the advantage of caching in real time. It does this by adding a random user to the list of users returned by the API request. It also adds a random delay to it:

export default async function apiFetch(...args) {
  await delay(Math.ceil(400 + Math.random() * 300));
  const res = await fetch(...args);
  const json = await res.json();
  json.data.push(getFakeUser());
  return json;
}

function delay(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

The getFakeUser() function here is responsible for creating a fake user object.

With these changes, our API is more real than before.

It has a random delay in responding.
It returns slightly different data for the same requests.

Given this, when we change the page prop passed to the Component from our main component, we can see the API caching in action. Try clicking the Toggle button once every few seconds in this CodeSandbox and you should see behavior like this:

If you look closely, a few things happen.

When the app starts and is in its default state, we see a list of seven users. Take note of the last user on the list since it is the user that will be randomly modified the next time this request is sent.
When we click on Toggle for the first time, it waits for a small amount of time (400-700ms) and then updates the list to the next page.
Now, we are on the second page. Again take note of the last user in the list.
Now, we click on Toggle again, and the app will go back to the first page. Notice that now the last entry is still the same user we noted down in Step 1, and then it later changes to the new (random) user. This is because, initially, the cache was being shown, and then the actual response kicked in.
We click on Toggle again. The same phenomenon happens. The cached response from last time is loaded instantly, and then new data is fetched, and so we see the last entry update from what we noted down in Step 3.

This is it, the stale-while-refresh caching we were looking for. But this approach suffers from a code duplication issue. Let's see how it goes if we have another data-fetching component with caching. This component shows the items differently from our first component.

Adding Stale-while-refresh to Another Component

We can do this by simply copying the logic from the first component. Our second component shows a list of cats:

const CACHE = {};

export default class Component2 extends React.Component {
  state = { cats: [] };

  componentDidMount() {
    this.load();
  }

  load() {
    if (CACHE[this.props.page] !== undefined) {
      this.setState({ cats: CACHE[this.props.page] });
    }
    apiFetch(`https://reqres.in/api/cats?page=${this.props.page}`).then(
      json => {
        CACHE[this.props.page] = json.data;
        this.setState({ cats: json.data });
      }
    );
  }

  componentDidUpdate(prevProps) {
    if (prevProps.page !== this.props.page) {
      this.load();
    }
  }

  render() {
    const cats = this.state.cats.map(cat => (
      <p
        key={cat.id}
        style={{
          background: cat.color,
          padding: "4px",
          width: 240
        }}
      >
        {cat.name} (born {cat.year})
      </p>
    ));
    return <div>{cats}</div>;
  }
}

As you can see, the component logic involved here is pretty much the same as the first component. The only difference is in the requested endpoint and that it shows the list items differently.

Now, we show both these components side by side. You can see they behave similarly:

To achieve this result, we had to do a lot of code duplication. If we had multiple components like this, we would be duplicating too much code.

To solve it in a non-duplicating manner, we can have a Higher-order Component for fetching and caching data and passing it down as props. It's not ideal but it will work. But if we had to do multiple requests in a single component, having multiple Higher-order Components would get ugly really quickly.

Then, we have the render props pattern, which is probably the best way to do this in class components. It works perfectly, but then again, it is prone to "wrapper hell" and requires us to bind the current context at times. This is not a great developer experience and can lead to frustration and bugs.

This is where React Hooks save the day. They allow us to box component logic in a reusable container so that we can use it at multiple places. React Hooks were introduced in React 16.8 and they only work with function components. Before we get to React cache control, let's first see how we do simple data fetching in function components.

API Data Fetching in Function Components

To fetch API data in function components, we use useState and useEffect hooks.

useState is analogous to class components' state and setState. We use this hook to have atomic containers of state inside a function component.

useEffect is a lifecycle hook, and you can think of it as a combination of componentDidMount, componentDidUpdate, and componentWillUnmount. The second parameter passed to useEffect is called a dependency array. When the dependency array changes, the callback passed as the first argument to useEffect is run again.

Here is how we will use these hooks to implement data fetching:

import React, { useState, useEffect } from "react";

export default function Component({ page }) {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    fetch(`https://reqres.in/api/users?page=${page}`)
      .then(res => res.json())
      .then(json => {
        setUsers(json.data);
      });
  }, [page]);

  const usersDOM = users.map(user => (
    <p key={user.id}>
      <img
        src={user.avatar}
        alt={user.first_name}
        style={{ height: 24, width: 24 }}
      />
      {user.first_name} {user.last_name}
    </p>
  ));

  return <div>{usersDOM}</div>;
}

By specifying page as a dependency to useEffect, we instruct React to run our useEffect callback every time page is changed. This is just like componentDidUpdate. Also, useEffect always runs the first time so it works like componentDidMount too.

Stale-while-refresh in Function Components

We know that useEffect is similar to component lifecycle methods. So we can modify the callback function passed to it to create the stale-while-refresh caching we had in class components. Everything remains the same except the useEffect hook.

const CACHE = {};

export default function Component({ page }) {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    if (CACHE[page] !== undefined) {
      setUsers(CACHE[page]);
    }
    apiFetch(`https://reqres.in/api/users?page=${page}`).then(json => {
      CACHE[page] = json.data;
      setUsers(json.data);
    });
  }, [page]);

  // ... create usersDOM from users

  return <div>{usersDOM}</div>;
}

Thus, we have stale-while-refresh caching working in a function component.

We can do the same for the second component, that is, convert it to function and implement stale-while-refresh caching. The result will be identical to what we had in classes.

But that's not any better than class components, is it? So let's see how we can use the power of a custom hook to create modular stale-while-refresh logic that we can use across multiple components.

A Custom Stale-while-refresh Hook

First, let's narrow down the logic we want to move into a custom hook. If you look at the previous code, you know it's the useState and useEffect part. More specifically, this is the logic we want to modularize.

const [users, setUsers] = useState([]);

useEffect(() => {
  if (CACHE[page] !== undefined) {
    setUsers(CACHE[page]);
  }
  apiFetch(`https://reqres.in/api/users?page=${page}`).then(json => {
    CACHE[page] = json.data;
    setUsers(json.data);
  });
}, [page]);

Since we have to make it generic, we will have to make the URL dynamic. So we need to have url as an argument. We will need to update the caching logic, too, since multiple requests can have the same page value. Luckily, when page is included with the endpoint URL, it yields a unique value for every unique request. So we can just use the entire URL as a key for caching:

const [data, setData] = useState([]);

useEffect(() => {
  if (CACHE[url] !== undefined) {
    setData(CACHE[url]);
  }
  apiFetch(url).then(json => {
    CACHE[url] = json.data;
    setData(json.data);
  });
}, [url]);

That's pretty much it. After wrapping it inside a function, we will have our custom hook. Have a look below.

const CACHE = {};

export default function useStaleRefresh(url, defaultValue = []) {
  const [data, setData] = useState(defaultValue);

  useEffect(() => {
    // cacheID is how a cache is identified against a unique request
    const cacheID = url;
    // look in cache and set response if present
    if (CACHE[cacheID] !== undefined) {
      setData(CACHE[cacheID]);
    }
    // fetch new data
    apiFetch(url).then(newData => {
      CACHE[cacheID] = newData.data;
      setData(newData.data);
    });
  }, [url]);

  return data;
}

Notice we have added another argument called defaultValue to it. The default value of an API call can be different if you use this hook in multiple components. That's why we have made it customizable.

The same can be done for the data key in the newData object. If your custom hook returns a variety of data, you might want to just return newData and not newData.data and handle that traversal on the component side.

Now that we have our custom hook, which does the heavy lifting of stale-while-refresh caching, here is how we plug it into our components. Notice the sheer amount of code we were able to reduce. Our entire component is now just three statements. That's a big win.

import useStaleRefresh from "./useStaleRefresh";

export default function Component({ page }) {
  const users = useStaleRefresh(`https://reqres.in/api/users?page=${page}`, []);

  const usersDOM = users.map(user => (
    <p key={user.id}>
      <img
        src={user.avatar}
        alt={user.first_name}
        style={{ height: 24, width: 24 }}
      />
      {user.first_name} {user.last_name}
    </p>
  ));

  return <div>{usersDOM}</div>;
}

We can do the same for the second component. It will look like this:

export default function Component2({ page }) {
  const cats = useStaleRefresh(`https://reqres.in/api/cats?page=${page}`, []);

  // ... create catsDOM from cats

  return <div>{catsDOM}</div>;
}

It's easy to see how much boilerplate code we can save if we use this hook. The code looks better as well. If you want to see the entire app in action, head over to this CodeSandbox.

Adding a Loading Indicator to useStaleRefresh

Now that we have the basics on point, we can add more features to our custom hook. For example, we can add an isLoading value in the hook that is true whenever a unique request is sent and we don't have any cache to show in the meanwhile.

We do this by having a separate state for isLoading and setting it according to the state of the hook. That is, when no cached web content is available, we set it to true, otherwise we set it to false.

Here is the updated hook:

export default function useStaleRefresh(url, defaultValue = []) {
  const [data, setData] = useState(defaultValue);
  const [isLoading, setLoading] = useState(true);

  useEffect(() => {
    // cacheID is how a cache is identified against a unique request
    const cacheID = url;
    // look in cache and set response if present
    if (CACHE[cacheID] !== undefined) {
      setData(CACHE[cacheID]);
      setLoading(false);
    } else {
      // else make sure loading set to true
      setLoading(true);
    }
    // fetch new data
    apiFetch(url).then(newData => {
      CACHE[cacheID] = newData.data;
      setData(newData.data);
      setLoading(false);
    });
  }, [url]);

  return [data, isLoading];
}

We can now use the new isLoading value in our components.

export default function Component({ page }) {
  const [users, isLoading] = useStaleRefresh(
    `https://reqres.in/api/users?page=${page}`,
    []
  );

  if (isLoading) {
    return <div>Loading</div>;
  }

  // ... create usersDOM from users

  return <div>{usersDOM}</div>;
}

Notice that with that done, you see "Loading" text when a unique request is sent for the first time and no cache is present.

Making useStaleRefresh Support Any async Function

We can make our custom hook even more powerful by making it support any async function rather than just GET network requests. The basic idea behind it will remain the same.

In the hook, you call an async function that returns a value after some time.
Each unique call to an async function is properly cached.

A simple concatenation of function.name and arguments will work as a cache key for our use case. Using that, this is how our hook will look:

import { useState, useEffect, useRef } from "react";
import isEqual from "lodash/isEqual";
const CACHE = {};

export default function useStaleRefresh(fn, args, defaultValue = []) {
  const prevArgs = useRef(null);
  const [data, setData] = useState(defaultValue);
  const [isLoading, setLoading] = useState(true);

  useEffect(() => {
    // args is an object so deep compare to rule out false changes
    if (isEqual(args, prevArgs.current)) {
      return;
    }
    // cacheID is how a cache is identified against a unique request
    const cacheID = hashArgs(fn.name, ...args);
    // look in cache and set response if present
    if (CACHE[cacheID] !== undefined) {
      setData(CACHE[cacheID]);
      setLoading(false);
    } else {
      // else make sure loading set to true
      setLoading(true);
    }
    // fetch new data
    fn(...args).then(newData => {
      CACHE[cacheID] = newData;
      setData(newData);
      setLoading(false);
    });
  }, [args, fn]);

  useEffect(() => {
    prevArgs.current = args;
  });

  return [data, isLoading];
}

function hashArgs(...args) {
  return args.reduce((acc, arg) => stringify(arg) + ":" + acc, "");
}

function stringify(val) {
  return typeof val === "object" ? JSON.stringify(val) : String(val);
}

As you can see, we are using a combination of function name and its stringified arguments to uniquely identify a function call and thus cache it. This works for our simple app, but this algorithm is prone to collisions and slow comparisons. (With unserializable arguments, it won't work at all.) So for real-world apps, a proper hashing algorithm is more appropriate.

Another thing to note here is the use of useRef. useRef is used to persist data through the entire lifecycle of the enclosing component. Since args is an array---which is an object in JavaScript---every re-render of the component using the hook causes the args reference pointer to change. But args is part of the dependency list in our first useEffect. So args changing can make our useEffect run even when nothing changed. To counter that, we do a deep-comparison between old and current args using isEqual and only let the useEffect callback run if args actually changed.

Now, we can use this new useStaleRefresh hook as follows. Notice the change in defaultValue here. Since it's a general-purpose hook, we are not relying on our hook to return the data key in the response object.

export default function Component({ page }) {
  const [users, isLoading] = useStaleRefresh(
    apiFetch,
    [`https://reqres.in/api/users?page=${page}`],
    { data: [] }
  );

  if (isLoading) {
    return <div>Loading</div>;
  }

  const usersDOM = users.data.map(user => (
    <p key={user.id}>
      <img
        src={user.avatar}
        alt={user.first_name}
        style={{ height: 24, width: 24 }}
      />
      {user.first_name} {user.last_name}
    </p>
  ));

  return <div>{usersDOM}</div>;
}

You can find the entire code in this CodeSandbox.

Conclusion

The useStaleRefresh hook we created in this article is a proof of concept that shows what's possible with React Hooks. Try to play with the code and see if you can fit it into your application.

Alternatively, you can also try leveraging stale-while-revalidate via a popular, well-maintained open-source library like swr or react-query. Both are powerful libraries and support a host of features that help with API requests.

React Hooks are a game-changer. They allow us to share component logic elegantly. This was not possible before because the component state, lifecycle methods, and rendering were all packaged into one entity: class components. Now, we can have different modules for all of them. This is great for composability and writing better code. I am using function components and hooks for all the new React code I write, and I highly recommend this to all React developers.

This article was first posted on Toptal's Engineering Blog

How to get guidance and mentorship as a Computer Science college fresher

Avi Aryan — Wed, 01 Jan 2020 10:32:00 +0000

I get some requests from students asking for guidance and mentorship. But I don’t have the time. So I am writing a post which will be more valuable than any mentorship I can give, provided you follow it.

It involves learning using free online resources. So there’s no reason why you can’t do this. We will be using only three websites for our learning needs.

Let’s go!

0. Learn a programming language

You will need to learn a programming language to kickstart your Computer Science journey. Don’t worry about getting good at it yet. Knowing the basics will do. I would recommend C. But you can start with Python if you find it overwhelming. At this point, the programming language you choose doesn’t matter. So just get started with anything.

1. HackerRank

As a Computer Science graduate, you need a basic understanding of algorithms and data structures. HackerRank has a beginner-friendly interface and it’s a great place to learn and practice them. We will concentrate on only 3 sections on the website.

Solving 150 problems from the above sections (combined) gives you a good base. 50 from each. That’s your target.

If you don’t understand something, google it. Then google it (drill-down) more. People have written articles and made videos on everything.

2. FreeCodeCamp

Once you have some algorithm foundations, we can move into software development. FreeCodeCamp is a great start to this. It has an extensive tutorial for learning how to make websites and web-apps from scratch. You can go through its curriculum. Complete it.

Also join their forum so that you can discuss with other learners, ask questions and help others.

3. Coursera

After you have a working knowledge of algorithms and making web-apps, you can go to Coursera. It has free courses on everything. The ‘free’ part is not straight-forward so please refer to this article.

In Coursera, search for what you want to learn, and then learn it.

If you are not sure what to learn, the Computer Science section can give you some ideas.

Pick any course you want and go with it. All courses are of high-quality. The rating for the course shows that.

Example - Here are the specializations (i.e. a collection of courses) to learn Android Development, Game Development and Python.

Search for anything and you will find it. Then learn it, if you want. Keep doing this over and over.

If for some reason, you can’t get a course for free, apply for their financial aid. You will get accepted. They are very gracious towards students.

How do I know if I am on the right path and learning the right thing?

Don’t worry about learning the right thing. Learn anything that interests you and sounds right. Learning things on your own will make you a better learner. This will help you pick up anything in the future. And that trait alone is all you need to have a great career in tech. So in short, just keep learning.

What’s next?

After you have been through a few courses and are comfortable writing code and making things, you should participate in Google Summer of Code. I have a step-by-step guide for it as well.

Conclusion

If you follow all the steps above, you will reach a point where you will be able to self-mentor yourself. You will know what things to learn and what to avoid. When to contact someone for a query and when to google it yourself. It’s important to get this feeling for yourself because tech is ever-changing. That’s why I am not a fan of step-by-step mentorships in tech.

Explore the wild, develop your senses, and keep going. You will soon reach a good place in your career.

Best of luck!

First posted on my blog

Some helpful Bash scripts I use daily

Avi Aryan — Wed, 25 Dec 2019 13:00:10 +0000

I posted a tweet about how investing time learning Bash scripting and various command-line tools is always worth it.

Every time I learn a command-line tool, I am like how did I work without this. Command-line tools are awesome. In this email, I will talk about a few bash scripts or aliases I use regularly. You should find a few of them useful in your digital life.

Preventing system sleep in Mac

System sleep in Mac can be a huge problem if you have an ongoing task like a large download as it stops the task. So I use this alias to prevent my Mac from sleeping.

alias nosleep=caffeinate -t 360000

I place this in my .bashrc file. The parameter 360000 is seconds to keep awake so this command keeps my Mac awake for 100 hours, enough time to finish that download.

Counting lines of code in a project

While working on some large projects, I like to keep track of how much work has been done. This one-liner helps to do so.

alias sloc="git ls-files \"*.js*\" \"*.scss\" | xargs wc -l"

This is currently set to include js, jsx , json and scss as source code files. Here is how the output looks like.

View list of aliases in your source file

If you have lots of aliases in your source file and tend to forget what you named them, this command will help. I keep all my aliases in a file called mymacrc which is further included in .bashrc using source ~/mymacrc.

So if I want to see the list of all aliases, I use this.

alias lsalias="grep -in --color -e '^alias\s+*' ~/mymacrc | sed 's/alias //' | grep --color -e ':[a-z][a-z0-9]*'"

Remove Dangling Docker images

Dangling Docker images are temporary images created by Docker to run a container. You can see them by running docker images. They have no name and are usually copies of their parent image. Although, they still take up disk space and for some reason, aren’t removed by Docker as quickly as they should be.

To remove them, I have this one-liner.

alias dcdangling="docker rmi \$(docker images -f \"dangling=true\" -q)"

Back up key files to Dropbox

Dropbox recently stopped supporting sync within symlinks. If you are like me, you probably used Dropbox just for that. Needless to say, I was disappointed. But then I found another way to sync to Dropbox. By using rsync.

But rsync doesn’t work with Dropbox directly. There is a wrapper over rsync called rclone that can do this for us.

Here is the code that syncs a folder in my HOME directory called syncs/osxdropbox to the Dropbox root folder called osxrsync.

rclone sync -L --exclude ".DS_Store" /Users/aviaryan/syncs/osxdropbox dropbox:osxrsync

This directory, in turn, contains symlinks to all other folders I want to sync. For example, here is the list of folders I am syncing to Dropbox.

v="/Users/aviaryan"
d="$v/syncs/osxdropbox"

ln -s "$v/scripts" "$d/scripts"
ln -s "$v/.ssh" "$d/.ssh"
ln -s "$v/Documents" "$d/Documents"
ln -s "$v/AlfredSettings" "$d/AlfredSettings"
ln -s "$v/mymacrc" "$d/mymacrc"

And you can see the same in my Dropbox.

But running rclone every time is not a good idea. To do it automatically, I use the system’s cron.

# edit crontab
crontab -e
# add a line for our cron job
0 14 * * * rclone sync -L --exclude ".DS_Store" /Users/aviaryan/syncs/osxdropbox dropbox:osxrsync

The above cron job runs the dropbox backup every day at 2 pm. Since my system is usually switched on at 2 pm, it works great for me.

EDIT - Forgot that I had a GitHub repo of some actual bash scripts. Check it out. It's a good collection. 😀

aviaryan / utility-bash-scripts

🤓 Useful bash scripts to do automatable tasks with a single command

🤓 Utility bash scripts

Utility bash scripts to do automatable tasks with a single command. We have scripts to download youtube videos, download music from youtube, convert media files, etc.

Contribute and add your secret script.

📝 NOTES

Download scripts download to ~/Downloads/ folder. For videos, they download to ~/Downloads/Videos and for audio, they download to ~/Downloads/Music.

For best results, clone this git repo to a fixed location on your computer and add it to $PATH.

cd ~
git clone https://github.com/aviaryan/utility-bash-scripts.git utility-scripts
cd utility-scripts
export PATH="$(pwd):$PATH"

📜 SCRIPTS

🔻 Download video from YouTube in MP4 format

Script: youtube-video
Dependencies: youtube-dl, ffmpeg, aria2c (optional)

youtube-video "https://www.youtube.com/watch?v=HgfojLtSBTM"

🔀 Merge video and audio together

Script: vamerge
Dependencies: ffmpeg

vamerge <path to video file> <path to audio file>
# the order is important, first video, then audio

…

View on GitHub

First published in my newsletter.

I took a break to fight burnout

Avi Aryan — Wed, 25 Dec 2019 12:57:34 +0000

Burnout. Chances are, most of you are familiar with it. But for someone new to this career, an introduction is due.

Burnout is a state of mental, physical and emotional exhaustion. Often you don’t realize when it starts happening. Finding why it is happening is even harder. It is very common in our field of work.

Our jobs require us to work from a computer, 8 hours a day, 5 days a week. Humans weren’t like this until the last 150 years or so. So a 9-5 office desk schedule is un-natural. But that’s not it.

Our work can get repetitive over time. This creates boredom and lethargy. It can also get challenging at times, leaving us mentally exhausted after a full day of work. If many such days go by, the mental damage compounds.

Similarly, our work requires minimum physical movements. This creates a feedback loop of reducing physical movements. Soon we find ourselves not wanting to do large physical movements. This tricks us into thinking we are physically exhausted.

If you are a remote worker, the lack of human interaction can make you socially inept. Humans are social creatures. Lack of social interactions makes us feel emotionally drained.

So burnout is inevitable in this career. Learning to recognize it or avoid it altogether is KEY.

I realized I was getting into a similar situation recently. So I decided to take a 7-day leave. I did no work at that time. This worked wonders. I felt recharged and was looking forward to getting back to work by the 4th day. After coming back, the results spoke for themselves.

So if you feel similar, take a break. Try a 2-day complete disconnect from work for starters. I am sure it will help you. If it doesn’t, try a longer break.

There are also ways to reduce burnout on a day to day basis.

You can join a gym or put something physical into your routine. This will help you act more like humans from 150 years ago, tricking your brain into feeling more okay.

You can also start a hobby apart from work. A hobby which doesn’t involve computers. Think gardening, cooking, playing music.

Competing in a sport or activity works even better. Since you are competing, you want to win. You will be 100% attentive when you do that activity. This guarantees that you will disconnect from work, giving you a proper break.

These are my top tricks to beat burnout. What are you doing to beat this devil?

First published in my newsletter.

Should you keep your code dependency-free?

Avi Aryan — Mon, 25 Nov 2019 03:25:10 +0000

I posted this tweet on Twitter about a trending JS library 🤷🏻‍♂️ called Immer. Immer is a small library that helps to work with immutable data in JavaScript.

Its main purpose is helping create immutable objects which are a big pain point in the language. That’s because objects are copied and compared by reference. Hence it’s easy to do something wrong when working with them. Take a look below.

obj1 = {a: 2}
// { a:2 }
obj2 = obj1
// { a:2 }
obj2.a = 3
// 3
obj1 === obj2
// true (but why, didn't I modify obj2?)

By the way, here is my tweet. I was particularly excited about Immer because it helps with deep state updates in React. No more messing around with map, filter and the whole functional programming squad.

Immediately someone tweeted back about the problems of using yet another library and how it is similar to the jQuery hell. In jQuery, we have a plugin for every feature you want to add. Think parallax, modal, spinners, and whatnot. If the developer is not careful, the jQuery app soon becomes tangled because of the many non-standardised dependencies. This makes it hard to maintain.

I partly agree.

Reducing dependencies which are like out-of-your-control pieces in an application is certainly important. They also bloat the app and increase the maintenance burden. If you are not careful while using them, they can slow it down as well.

Imagine using a website or an app that takes many seconds to load or takes a lot of time to download. It’s a pain. It drives a fraction of users away and for those that stay, it wastes their time. This should be avoided when possible.

But not using a helpful dependency can also mean we are creating the solution ourselves. This can result in more time to market and more chances of bugs. Libraries and frameworks like Immer, Bootstrap, React are extensively tested to remove bugs. Creating your own solution means you will have bugs that will crawl out to the end-users.

Again something we don’t want.

As a developer, our most important job is to create things that solve problems. It’s very easy to want to use a library or a framework for the sake of it. But we should do so while focusing on the end goal, which is, fulfilling human needs, desires, and fantasies. Anything else is just not of the same value.

This reminds me of a tweet I retweeted recently.

Coding and building is also a means to an end. Sure, it can be fun for us (it is for me) but we must not forget why we do it for. If the tool we build is not solving someone’s problem, it is not as impactful as building a tool that solves someone’s problem.

For that, we should use whatever works. Whatever solves the problem correctly, most efficiently, for the largest number of people.

This article was first posted on my website.