DEV Community: Ibrahim Khan

React: Managing Application State only with Context

Ibrahim Khan — Sun, 02 Aug 2020 17:31:47 +0000

TL&DR: This is an experimental attempt to show that Context can be used for State Management, and is used by libraries.

Also, you can have a look around THIS issue on GitHub

What is Context?

The Context was React's answer to "props drilling", a mechanism to share data between multiple child components through a common parent component.

Context is like Refs, but it comes with providers. It means, every Context has it's own provider component, and the shared value is passed through the props of that component.

const AppContext = React.createContext();

function SomeComponent() {
    return (
        <AppContext.Provider value={initialValue}>
            <ChildComponentOne />
            <ClildComponentTwo />
        </AppContext.Provider>
    )
}

Context for State Management?

If you are already into React, then you also know not to use Context directly. That's because the shared value is passed through the props of the provider component. So, when the reference to that shared value changes, the parent component always triggers a re-renders from the provided component. This is visible if the profile the Context example from React's documentation.

I re-created the example, then profiled it by enabling highlight on re-render of the component. The App consists of four components - two components only trigger increment, the other two only shows the values. You can find my code HERE. We can see bellow that all components are re-rendering on every single state change, along with the main app component.

Then why Context?

Given this behavior, it might seem impractical to use Context. But if you dig inside the state management libraries for React, you will see that they use Context underneath (namely MobX. So what's the difference?

How we pass the value through the provider makes all the difference. We pass the value through the Provider's props. So, if the reference of that value changes, it triggers re-render. So, if we want to stop that unnecessary re-render, we have to update values without changing the reference.

Start the experiment already!

Let's start with a class that will be used as the primitive to store data.

// TypeScript

type Callback = {
  id: string,
  cb: () => void,
};

class ReactiveVariable<T> {
  private value: T | undefined;
  private reactions: Callback[] = [];

  setValue(v: T): void {
    this.value = v;
    this.reactions.forEach(r => r.cb());
  }

  getValue(): T | undefined {
    return this.value;
  }

  addReaction(cb: Callback['cb']): string {
    const id: string = `${Math.random() * 1000}-${Math.random() * 1000}-${Math.random() * 1000}`;
    this.reactions.push({ id, cb });
    return id;
  }

  removeReaction(id: string): void {
    this.reactions = this.reactions.filter(r => r.id !== id);
  }
}

This is a generic class that can store any type of data. The difference is that it can keep a list of the callback functions that will be executed if the stored value changes.

Now, let's create our state.

// TypeScript

class ReactiveStateClass {
  inc1: ReactiveVariable<number> = new ReactiveVariable();
  inc2: ReactiveVariable<number> = new ReactiveVariable();

  increment1(): void {
    const currentValue = this.inc1.getValue() ?? 0; 
    this.inc1.setValue(currentValue + 1);
  }

  increment2(): void {
    const currentValue = this.inc2.getValue() ?? 0; 
    this.inc2.setValue(currentValue + 1);
  }
}

export const ReactiveState = new ReactiveStateClass();

Now we have two variables that store two numbers in our state. We can call increment1() and increment2() function to increment those two numbers.

Let's create our Context.

// Context
const IncrementContext = React.createContext(ReactiveState);

To keep the components clean, we can write hooks that will connect to the Context and apply reaction when the value changes. We can expose the updated value through React.useState() to trigger re-render when the value changes.

// TypeScript

function useInc1(): number | undefined {
  const [value, setValue] = React.useState<number>();
  const context = React.useContext(IncrementContext);
  React.useEffect(() => {
    const id = context.inc1.addReaction(() => setValue(context.inc1.getValue()));
    return () => context.inc1.removeReaction(id);
  });
  return value;
}

function useInc2(): number | undefined {
  const [value, setValue] = React.useState<number>();
  const context = React.useContext(IncrementContext);
  React.useEffect(() => {
    const id = context.inc2.addReaction(() => setValue(context.inc2.getValue()));
    return () => context.inc2.removeReaction(id);
  });
  return value;
}

Now, let's connect the Context with our application.

// TypeScript

// Render value
function IncrementOneView() {
  const inc1 = useInc1();
  return (
    <div>
      Increment One : {inc1}
    </div>
  );
}

// Render value
function IncrementTwoView() {
  const inc2 = useInc2();
  return (
    <div>
      Increment Two : {inc2}
    </div>
  );
}

// Trigger increment
function IncrementOneButton() {
  const context = React.useContext(IncrementContext);
  return (
    <div>
      <button
        onClick={() => context.increment1()}
      >
        Increment One
      </button>
    </div>
  )
}

// Trigger increment
function IncrementTwoButton() {
  const context = React.useContext(IncrementContext);
  return (
    <div>
      <button
        onClick={() => context.increment2()}
      >
        Increment Two
      </button>
    </div>
  )
}

// Our main application
function App() {
  return (
    <IncrementContext.Provider value={ReactiveState}>
      <div style={ViewStyle}>
        <IncrementOneView />
        <IncrementTwoView />
        <br />
        <IncrementOneButton />
        <IncrementTwoButton />
      </div>
    </IncrementContext.Provider>
  );
}

Now that everything is set up, let's profile it with the Dev Tools.

As we can see, we are re-rendering only the child that needs to be re-rendered!

You can find the source code HERE if you want to have a look at it.

How I practice Problem Solving in JavaScript with Jest

Ibrahim Khan — Sat, 15 Feb 2020 17:59:35 +0000

Algorithms and data structure are the founding pillars for any software engineer. But it the knowledge depends on the practice of it. Most of the time in my work, I don't need to use all of those algorithms. That's why I try to solve problems from Leet Code so that I can stay in the loop and don't forget all the basics (duhh 🤨).

But Why?

One problem that I consistenty face is that, when I change the code to improve my implementation, it takes too much time on LeetCode to run my code and return the results. At first I used to keep and array of inputs and outputs, and compare them manually. Although it was tedious, it did what I wanted to do, run all the cases locally for faster results. When I started following TDD (Test-Driven Development) process at my workplace, it came to my mind that I can write small test-cases for my implementation.

How I do it now?

Initially I created an Node.js project with NPM

npm init

Then installed Jest

npm install --save jest

The project structure looks like this -

./LeetCode
    |--- main.js
    |--- main.test.js
    |--- package.json

My package.json looks like this -

{
  "name": "LeetCode",

  "version": "1.0.0",
  "description": "",
  "scripts": {
    "start": "node main.js",
    "test": "jest"
  },
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "jest": "^24.9.0"
  }
}

I write my implementation on main.js -

const romanMap = {
  '1': 'I', '2': 'II', '3': 'III', '4': 'IV', '5': 'V', '6': 'VI', '7': 'VII', '8': 'VIII', '9': 'IX',
  '10': 'X'
}

/**
 * @param {number} num
 * @return {string}
 */
var intToRoman = function(num) {
    return romanMap[num.toString()];
};

module.exports = intToRoman;

Then write my test-cases on main.test.js -

const func = require('./main');

test('Outputs III', () => {
  expect(func(3)).toBe('III');
});

test('Outputs IV', () => {
  expect(func(5)).toBe('IV');
});

test('Outputs IX', () => {
  expect(func(9)).toBe('IX');
});

Now I can run all test-cases at once -

npm test

Now, let's say that my implementation was wrong. What will happen then?

Jest will print out the diff of the expected output and the output from running the test.

On LeetCode, they don't provide all the test-cases. So, I start with the sample output, then gradually add new cases when I get error after submitting my code. That way, I can write a basic solution and gradually build my testing code. When that is accepted, then I can easily write more optimized code and test them locally. But of course I submit that code on LeetCode afterwards for checking.

Should you do it too?

No really, that depends on how you try to approach it. Everyone has their own flow of keeping their basic on the check. But, do tell me how you do it.

Some hurdles of Github Actions 🐱‍👤

Ibrahim Khan — Fri, 10 Jan 2020 14:54:39 +0000

Github Actions is the new kid around the block for workflow automation. DevOps guys are having the day for it, as it makes a heck of a lot easier for them to implement CI/CD 🔥 from the same place they host their project.

Last month, I worked on setting up a workflow for building a deployment pipeline. The project that I’m part of, is a desktop application 🖥 built on Electron.

You might be thinking 🤔, why build a desktop app on Github’s Actions? Because the build process is quite cumbersome and take a pretty big chunk of the developers precious time 😒. As we were already planning to build a CI/CD pipeline, we thought to give it a try with Github Actions 😁 (as we already host our project on Github privately).

Disclaimer: This post applies to Github’s Linux and Windows runners, as I have tested on those. Although Mac OS runner isn’t much different then the Linux runner. You can find more about them HERE.

Testing the workflow locally

When I'm trying out something new 🐱‍🏍, the first thing I try is to set up a local environment to test it out 🧗‍♂️. Can it be done for Github Actions? The answer is not definitive 🤔. We can use our own Docker Image as a custom runner, and test it locally on that local Docker Image. We can’t create the exact environment to mock the workflow, at least I couldn’t find any solution.

Complex processes

Setting up a YAML configuration for projects that already use some kind of framework, or has a rich set of build tools is really easy ✌. But when we are writing configuration for an application where the build 🏭 requires multiple process, with sources from different languages and frameworks, it kinda becomes messy to keep track of the process flow. Sure you can divide the processes into “Jobs” but that has its own pitfall 👎, which I’ll talk about later in this post.

Actions from Marketplace

On the Github Marketplace, there are quite a lot of actions written by other developers 👩‍💻. These actions can be written in two ways, using Docker configuration or using JavaScript. While JavaScript actions run on all platforms, actions written in Docker configuration can only run on Linux. So, we might find some action that cuts down your task into half, but still can’t use it, only because we are using Non-Linux runner.

Data persistence on a workflow

In a complex build 🏭 process, you may want to pass some information from one job to another, to build a flow. The only way to pass data in-between jobs, is to use Github Artifacts. They aren’t cheap either. You can’t delete an artifact manually 😲. GitHub stores artifacts for 90 days for pushes and pull requests. Storing artifacts uses storage space on GitHub. Also, for private repositories like ours, there is a fixed amount of “Free Minutes” and “Storage” after which it will start billing 💵. One good thing is that files uploaded as artifacts are compressed as “zip”. So, if you are uploading log files or reports, you may not need to think about the storage, at least 😌.

Limited flexibility for Actions

One particular problem I faced 🤨 while using an action from marketplace is that, we can’t set working-directory when executing them. That means, those actions must always be executed from the root directory 😬. This won’t matter if we are building a single project. But if it’s a monorepo, then the actions won’t work if it doesn’t accept the directory path as parameter. In my case, the action accepted a directory path, so I was saved somehow 😌.

That’s it for today folks. See you, when I see you 🐱‍👤.

Cover Image Credit: kaleidico