DEV Community: mihomihouk

How to be a web accessibility practitioner in two days

mihomihouk — Sun, 30 Jul 2023 23:17:28 +0000

Introduction

I first learned about accessibility from a senior engineer when I was looking for a new role as a Junior software engineer. He told me that while more and more companies are interested in accessibility, not many people have hands-on experience let alone learn about it themselves, so adding it to my skill set would make me stand out.

As this story implies, accessibility is currently considered as a "nice-to-have skill" rather than compulsory. Recent research that evaluated 1 million websites shows that an average of 50 errors per page was detected and 96.3% of homepages failed to meet WCAG 2 standards. But the more I learn about it, the stronger I came to feel that accessibility is an essential process that every software development should include in its life cycle.

In this article, I will share how I learned and improved the accessibility of my project within just two days without prior knowledge.

Day 1: Learn about accessibility

Just like learning new languages and frameworks, accessibility requires some research and learning. So I dedicated one day to learning about the background and methods of accessibility.

Understand the background

The goals here are to:

Understand why accessibility is important.
Understand how people with disabilities are experiencing inaccessible websites/apps.

To achieve this, I used different resources:

Videos on Youtube (e.g., Accessible Web Design: What Is It & How To Do It)
Podcast (e.g., Javascript Jabber 362: Accessibility with Chris DeMars)
Blog article (e.g.,Despite efforts, businesses struggle with accessibility)

Keeping the goals in mind, I watched/read/listened to these materials just to get an overview and extract necessary information.

While it's ultimately up to you, I wouldn't recommend using WCAG 2.1 document just yet as the volume might be overwhelming and it can easily put you off if you are still new to this area.

Below are the examples of what I learned from this learning:

There are many types of disabilities(e.g.,visual impairment, deafness and hearing loss, limited movement, speech disabilities, photosensitivity).
Disability can be temporal (e.g., weakened eyesight with ageing or sudden injury).
Disability is situational (= certain bodily and cognitive characters become "disability" due to the environment surrounding them).
There are three different accessibility levels: AAA(highest level), AA(a level that most development teams should be aiming to meet) and A.
Currently, the UK law asks companies to make a "reasonable adjustment" to make their website/applications accessible to people with disabilities (Section 20 and 29 of Equality Act 2010).
There are different views towards accessibility (time constraints? cost? good branding? moral responsibility?)
Accessible website = SEO friendly

Understand the accessibility level of our website/application

After learning about the context of accessibility, I checked my current personal project to see how accessible it is. First I generated a Lighthouse report.

Lighthouse is an amazing open-source Google Chrome tool that helps us improve the quality of our website/application. To use it, you access the page you want to test in your Chrome browser and find Lighthouse in the Dev tool. After selecting the accessibility option and running the audit, you will see a report that shows the accessibility level of the page and the issues that should be addressed to improve accessibility.

In my application, for example, I got a warning about the lack of names for some buttons.

And then, I navigated the deployed website with assistive technologies to gain a better understanding of how my application would be experienced by people with disabilities.

Keyboard (Tab key to move up and down)
Screen reader (For those with visual impairment. As a Mac user, I used Voice over.)
Sim Daltonism (For colour blindness.)

Sim Daltonism is an amazing tool. You can use the tool just like a filter through which you can see screens through the eyes of people with colour blindness.

As you can see, the text "Log in" inside the red circle is almost invisible due to poor colour contrast. This is only noticeable because I am using Sim Daltonism's filter here.

Learn the solutions and make your Accessible checklist

I learned about potential audiences I could reach out to by improving accessibility and accessibility concerns of my current application. So in this third step, I focused on learning how to solve these problems.

Learn from real-world examples of accessibility

Just as I did in my first step, I used Youtube videos and articles to educate myself. In this process, I spent more time learning from real-world front-end development examples. I highly recommend reading what Octopus Energy has been doing on its website and application for its users. This company is very serious about accessibility and has actively documented its accessibility journey to make accessibility implementable for developers like you and me!

Iterate your accessible checklist

To facilitate the future process, I made a checklist and added accessibility coding techniques I learned from videos and articles to it. Every website and application has different UI and functions, so it is important to make a customised list that suits your project.

If you want to make it more comprehensive, WCAG quick reference should give you a thorough list of points to cover.

Day 2: Apply accessibility to your project

On my second day, I applied all my learnings to my current project.

Use tools as your guide

I already touched Lighthouse earlier and I used the tool again to test the accessibility of every page in my application. All I needed to do is to read the report and make adjustments such as adding attributes and tabIndex={0} to make UI readable by screen reader and accessible by keyboard and fixing semantic HTML.

While Lighthouse undoubtedly facilitates web accessibility, it is not a panacea. For example, the image below shows the accessibility rate of the page is 100%. But as we looked at earlier, the colour contrast of this page is inaccessible to people with colour blindness.

Other useful tools

To compensate for Lighthouse reports, I used several other materials and conducted manual testing. Here I share some websites and browser extensions that I found useful to improve the accessibility of my web application.

Colour contrast

To achieve AAA-level colour contrast, I used the following websites:

WebAIM is a contrast checker where we can add two colours in the inputs to see their contrast ratio and how well the ratio meets accessibility standards.

Accessible Colour Contrast, on the other hand, shows you options for accessible colour combinations. You can filter the options depending on which accessibility level you are aiming at. Using this website, I chose the primary and secondary colours of my application.

Let's have a look at my landing page which used to be very inaccessible. In the image with Sim Daltonism's filter below, we can clearly see the "Log in" text. This is a good example of how much difference we can make by just changing the colour contrast.

HTML Outline

Messy or flat HTML structures confuse screen readers and hinder them from navigating websites/applications efficiently.

If you are a Google Chrome user, the following extensions surely help you find out whether the elements are properly organised.

Example: how my application changed after accessibility improvements

After the implementation, I found my web application fully functioning with keyboard navigation. Screen reader now clearly tells what users can expect from each element. There is no keyboard trap and colour contrasts are all AAA level.

Below shows how this implementation changed my application visually.

Before(sign up page):

After(sign up page):

Before(modal):

After(modal):

The landing page now looks a bit empty, but this is just the first iteration. Accessible websites and applications don't need to be boring.

But I was personally surprised to learn how quickly I could achieve this level of accessibility. And I'm sure it will only become easier as I experience more.

Conclusion

Ultimately, as Ashley Firth suggests in Practical Web Inclusion and Accessibility, accessibility should be a collaborative effort if we are part of collaborative projects. This means even if we are passionate about accessibility and include it in the code we write, if others are not on board, your websites/applications stay largely inaccessible to people with disabilities.

But it does not mean we have to wait until our boss asks us to start learning it. If we believe it's the right thing to do, we should keep learning it, improving our skills and sharing our experience with our colleagues.

To stay involved in web accessibility, we could either:

Find like-minded people to start a new project with accessibility practices.
Become an advocate to drive accessibility implementation in our organisations.
Join a company which has been already committed to accessibility.

Thanks for reading!

Please let me know your web accessibility experience and the tools you use to improve the accessibility of your websites and applications.

How to make a reusable button component with Typescript in React applications

mihomihouk — Fri, 21 Jul 2023 17:52:15 +0000

Introduction

Do you find your reusable component getting messier as your project develops? If so, it might be a good time to start refactoring it!

In this article, I will share one way to quickly improve the readability and maintainability of a reusable component using a button component as an example.

Cluttered button component

Here we have a reusable, but very cluttered button component.

import { Link, LinkProps } from 'react-router-dom';
import React, { CSSProperties } from 'react';
import classNames from 'classnames';
import { FadeLoader } from 'react-spinners';

const spinnerOverride: CSSProperties = {
  margin: '0 auto',
  top: '30px'
};

interface ButtonProps {
  className?: string;
  onClick?: () => void;
  to?: LinkProps['to'];
  children?: React.ReactNode;
  inNav?: boolean;
  isPrimary?: boolean;
  isSecondary?: boolean;
  isWarning?: boolean;
  disabled?: boolean;
  isLoading?: boolean;
  type: 'button' | 'reset' | 'submit' | undefined;
  testId?: string;
}
export const Button: React.FC<ButtonProps> = ({
  className,
  onClick,
  to,
  inNav,
  isPrimary,
  isSecondary,
  isWarning,
  type,
  testId,
  disabled,
  isLoading,
  children
}) => {
  const hrefTo = to ?? '#';
  if (isLoading) {
    return (
      <FadeLoader
        data-testid="loading"
        loading={isLoading}
        height={10}
        width={10}
        cssOverride={spinnerOverride}
        aria-label="Loading Spinner"
      />
    );
  }

  if (to) {
    return (
      <Link
        className={classNames(
          {
            'pl-0 lg:pl-3 py-2 rounded-3xl hover:bg-gray-300 ease-in duration-300':
              inNav
          },
          {
            'w-full bg-primary-500 text-white inline-block p-2 rounded-lg hover:bg-opacity-75 focus:outline-none focus:ring focus:border-primary-800':
              isPrimary
          },
          {
            'w-full bg-secondary-500 text-white inline-block p-2 rounded-lg hover:bg-opacity-75 focus:outline-none focus:ring focus:border-secondary-800':
              isSecondary
          },
          {
            'w-full bg-error-500 text-white inline-block p-2 rounded-lg hover:bg-opacity-75 focus:outline-none focus:ring focus:border-error-800':
              isWarning
          },
          {
            'cursor-not-allowed': disabled
          },
          className
        )}
        to={hrefTo}
      >
        <button
          className={classNames(
            'w-full',
            { 'flex gap-4': inNav },
            {
              'cursor-not-allowed': disabled
            }
          )}
          data-testid={testId}
          tabIndex={0}
          onClick={onClick}
          disabled={disabled}
          type={type}
        >
          {children}
        </button>
      </Link>
    );
  }

  return (
    <button
      className={classNames(
        {
          'w-full bg-primary-500 text-white inline-block p-2 rounded-lg hover:bg-opacity-75':
            isPrimary
        },
        {
          'w-full bg-secondary-500 text-white inline-block p-2 rounded-lg hover:bg-opacity-75':
            isSecondary
        },
        {
          'w-full bg-error-500 text-white inline-block p-2 rounded-lg hover:bg-opacity-75':
            isWarning
        },
        {
          'py-2 lg:pl-3 rounded-3xl hover:bg-gray-300 ease-in duration-300 flex gap-4 w-full ':
            inNav
        },
        {
          'cursor-not-allowed': disabled
        },
        className
      )}
      data-testid={testId}
      tabIndex={0}
      onClick={onClick}
      disabled={disabled}
      type={type}
    >
      {children}
    </button>
  );
};

As a project develops, it's common for a reusable component to start accepting more and more props to extend its versatility. Depending on where it's used, we might want to pass different styles, types, IDs for testing, accessibility attributes, and more to a component.

But is it really necessary to explicitly write every single prop when we type, destructure, and consume them like this?

Absolutely not!

Refactor a reusable component using JSX.IntrinsicElements

One way to improve the readability and maintainability of a reusable component is to leverage React types.

Let's perform some magic!

import { Link, LinkProps } from 'react-router-dom';
import React, { CSSProperties } from 'react';
import classNames from 'classnames';
import { FadeLoader } from 'react-spinners';

const spinnerOverride: CSSProperties = {
  margin: '0 auto',
  top: '30px'
};

type IntrinsicButtonProps = JSX.IntrinsicElements['button'];

interface ButtonProps extends IntrinsicButtonProps {
  to?: LinkProps['to'];
  inNav?: boolean;
  isPrimary?: boolean;
  isSecondary?: boolean;
  isWarning?: boolean;
  isLoading?: boolean;
}

export const Button: React.FC<ButtonProps> = ({
  className,
  to,
  inNav,
  isPrimary,
  isSecondary,
  isWarning,
  disabled,
  isLoading,
  children,
  ...props
}) => {
  const hrefTo = to ?? '#';
  if (isLoading) {
    return (
      <FadeLoader
        data-testid="loading"
        loading={isLoading}
        height={10}
        width={10}
        cssOverride={spinnerOverride}
        aria-label="Loading Spinner"
      />
    );
  }

  if (to) {
    return (
      <Link
        className={classNames(
          {
            'pl-0 lg:pl-3 py-2 rounded-3xl hover:bg-gray-300 ease-in duration-300':
              inNav
          },
          {
            'w-full bg-primary-500 text-white inline-block p-2 rounded-lg hover:bg-opacity-75 focus:outline-none focus:ring focus:border-primary-800':
              isPrimary
          },
          {
            'w-full bg-secondary-500 text-white inline-block p-2 rounded-lg hover:bg-opacity-75 focus:outline-none focus:ring focus:border-secondary-800':
              isSecondary
          },
          {
            'w-full bg-error-500 text-white inline-block p-2 rounded-lg hover:bg-opacity-75 focus:outline-none focus:ring focus:border-error-800':
              isWarning
          },
          {
            'cursor-not-allowed': disabled
          },
          className
        )}
        to={hrefTo}
      >
        <button
          className={classNames(
            'w-full',
            { 'flex gap-4': inNav },
            {
              'cursor-not-allowed': disabled
            }
          )}
          {...props}
        >
          {children}
        </button>
      </Link>
    );
  }

  return (
    <button
      className={classNames(
        {
          'w-full bg-primary-500 text-white inline-block p-2 rounded-lg hover:bg-opacity-75':
            isPrimary
        },
        {
          'w-full bg-secondary-500 text-white inline-block p-2 rounded-lg hover:bg-opacity-75':
            isSecondary
        },
        {
          'w-full bg-error-500 text-white inline-block p-2 rounded-lg hover:bg-opacity-75':
            isWarning
        },
        {
          'py-2 lg:pl-3 rounded-3xl hover:bg-gray-300 ease-in duration-300 flex gap-4 w-full ':
            inNav
        },
        {
          'cursor-not-allowed': disabled
        },
        className
      )}
      {...props}
    >
      {children}
    </button>
  );
};

Wow!

Can you see the difference from the previous code?
The amount of code clearly reduced, making the component a lot easier to read.

So what have been changed?

Change the type of the props

The biggest difference is how we declare the type of the props.

type IntrinsicButtonProps = JSX.IntrinsicElements['button'];

First, this line of code extends JSX.IntrinsicElements['button'], which includes all the standard attributes available for a element.


interface ButtonProps extends IntrinsicButtonProps {
  to?: LinkProps['to'];
  inNav?: boolean;
  isPrimary?: boolean;
  isSecondary?: boolean;
  isWarning?: boolean;
  isLoading?: boolean;
}

And then, we declare a new interface ButtonProps by adding custom attributes to IntrinsicButtonProps, which already has the basic button attributes.

Adjust the way to destructure and use props

The second difference is the way we destructure and use the props.

export const Button: React.FC<ButtonProps> = ({
  className,
  to,
  inNav,
  isPrimary,
  isSecondary,
  isWarning,
  disabled,
  isLoading,
  children,
  ...props
}) => {

<button
  className={classNames(
  'w-full',
  { 'flex gap-4': inNav },
  {
   'cursor-not-allowed': disabled
   }
  )}
  {...props}
>
 {children}
</button>

When destructing, we extract some items by explicitly writing each one of them while handling the rest by using spread operator.

The extraction is useful for an item used conditionally as you can see in my example. We pass the rest to button tag by again using spread operator.

That's it!

Final remark

I believe that enhancing the versatility of a reusable component necessities some refactoring.

Using the JSX.IntrinsicElements is one of the approach and we already see a huge improvement in code.

What is your strategy to extend the versatility of a reusable component without compromising the readability and maintainability?

I am keen to know!

Testing React Portals: A Real-Life Example for testing a modal

mihomihouk — Thu, 20 Jul 2023 17:16:53 +0000

Introduction

In React development, a portal is like a secret passage that lets you render components outside the usual DOM setup.

In this article, we'll dive into portals and how to test it properly with Jest/react-testing-library with my real example.

What is portal and when to use it

A portal is a mechanism that allows you to render components outside of the normal DOM hierarchy.

Imagine you want to render components like modals, dialogs, and tooltips without letting them affected by the position or styling of their parent elements. Placing the component in a portal works perfectly in this scenario while still allowing the component to consume and update context shared in the normal DOM tree.

When modal is hidden:

When modal is visible:

As you can see, the modal rendered into a portal is added outside of root!!

If you want to explore more, visit this page on React's website.

Custom modal as an example

Before discussing testing a portal component, I'll share how I set up my modal component.

import classNames from 'classnames';
import React from 'react';
import ReactDOM from 'react-dom';

interface ModalProps {
  children?: React.ReactNode;
  onDismiss?: () => void;
  className?: string;
}

export const Modal: React.FC<ModalProps> = ({
  children,
  onDismiss,
  className
}) => {
  React.useEffect(() => {
    const handleEscKey = (event: KeyboardEvent) => {
      if (event.key === 'Escape') {
        onDismiss && onDismiss();
      }
    };
    document.querySelector('body')?.classList.add('overflow-hidden');
    document.addEventListener('keydown', handleEscKey);

    return () => {
      document.querySelector('body')?.classList.remove('overflow-hidden');
      document.removeEventListener('keydown', handleEscKey);
    };
  }, [onDismiss]);

  return ReactDOM.createPortal(
    <div
      className="flex flex-col items-center fixed bottom-0 right-0 left-0 top-0 z-[1000] bg-[#1e1e1e99]"
      onClick={() => onDismiss?.()}
      data-testid="modal"
    >
      <div
        className={classNames(
          className,
          'sm:w-[600px] sm:h-[500px] md:w-[700px] md:h-[600px] absolute left-1/2 top-1/2 -translate-x-1/2 -translate-y-1/2 overflow-auto rounded-2xl bg-gray-800'
        )}
        onClick={(e) => e.stopPropagation()}
      >
        {children}
      </div>
    </div>,
    document.body
  );
};

I used createPortal API provided by React. Following the syntax createPortal(children, domNode, key?), I pass my modal component as the first parameter and document.body as a place I want to render the modal to the API.

App.tsx

import React from 'react';
import './index.css';
import { ModalsContainer } from './container/modals-container';
import { AppRoutes } from './routes/AppRoutes';

function App() {
  return (
    <>
      <AppRoutes />
      <ModalsContainer />
    </>
  );
}

export default App;

And I placed a group of modals (<ModalsContainer />) as well as other components (<AppRoutes />) in App component.

Test modal

Sorry to keep you waiting for so long. We can finally talk about how to test a portal.

If you want to skip ahead, please go straight into my final solution. But if you are curious enough, let's look at my testing strategies and the mistake I made first.

What I wanted to test

I wanted to verify that once a button is clicked, the modal opens properly.

Testing strategy

Update Redux state necessary for the test.
Render <App/> component and pass a particular route (in this case, a path to dashboard page).
Ensure the page is rendered properly.
Click a button that opens a modal.
Ensure the expected modal is successfully rendered by checking specific content inside the modal.

Initial code (don't do this)

To test the above step, I initially created the test code below:

import { renderWithProviders } from '../../util/test';
import '@testing-library/jest-dom';
import { screen, waitForElementToBeRemoved } from '@testing-library/react';
import { setupStore } from '../../store/store';
import { showModal } from '../../slices/modals-slice';
import { ModalType } from '../../interfaces/modal-type';
import App from '../../App';
import { setIsAuthenticated, setUser } from '../../slices/auth-slice';
import { mockUser } from '../../mocks/user';
import userEvent from '@testing-library/user-event';
import { server } from '../../mocks/server';
import { rest } from 'msw';
import config from '../../config';

const baseURL = config.apiUrl;

describe('Modal component', () => {
  it('should render modal when prompted', async () => {
    server.use(
      rest.get(`${baseURL}/post/get-posts`, (req, res, ctx) => {
        return res(ctx.json([]));
      })
    );
    const store = setupStore();
    store.dispatch(setIsAuthenticated(true));
    store.dispatch(setUser(mockUser));
    renderWithProviders(<App />, { store, initialRoutes: ['/dashboard'] });

    await waitForElementToBeRemoved(() => screen.queryByTestId('main loader'));
    expect(
      await screen.findByText('Create a new post to get started.')
    ).toBeInTheDocument();

    userEvent.click(screen.getByTestId('create-post-btn'));

    expect(screen.getByText('Create new post')).toBeInTheDocument();

  });
});

After running this test, I encountered the following error:

TestingLibraryElementError: Unable to find an element with the text: Create new post. This could be because the text is broken up by multiple elements. In this case, you can provide a function for your text matcher to make your matcher more flexible.

Oh nooooo!

I could ensure that all the testing steps were completed except for the last part:

Ensure an expected modal is successfully rendered by getting a text inside the modal.

React testing library fails to find a text inside the modal after clicking a button to open it.

Final code (definitely try this!)

Don't worry, this article has a happy ending.

After searching for a workaround, I found this issue thread on the React-testing-library Github page, which gave me a clear solution.

I applied it in my testing code...and ta-da!

Now I could see my test pass successfully!

Here is the testing code:

import { renderWithProviders } from '../../util/test';
import '@testing-library/jest-dom';
import {
  getQueriesForElement,
  screen,
  waitForElementToBeRemoved
} from '@testing-library/react';
import { setupStore } from '../../store/store';
import App from '../../App';
import { setIsAuthenticated, setUser } from '../../slices/auth-slice';
import { mockUser } from '../../mocks/user';
import userEvent from '@testing-library/user-event';
import { server } from '../../mocks/server';
import { rest } from 'msw';
import config from '../../config';

const baseURL = config.apiUrl;

describe('Modal component', () => {
  it('should render modal when prompted', async () => {
    server.use(
      rest.get(`${baseURL}/post/get-posts`, (req, res, ctx) => {
        return res(ctx.json([]));
      })
    );
    const store = setupStore();
    store.dispatch(setIsAuthenticated(true));
    store.dispatch(setUser(mockUser));
    const { baseElement } = renderWithProviders(<App />, {
      store,
      initialRoutes: ['/dashboard']
    });

    await waitForElementToBeRemoved(() => screen.queryByTestId('main loader'));
    expect(
      await screen.findByText('Create a new post to get started.')
    ).toBeInTheDocument();

    userEvent.click(screen.getByTestId('create-post-btn'));

    const modal = getQueriesForElement(baseElement).queryByTestId('modal');
    expect(modal).toBeInTheDocument();
  });
});

After this change, I could now see the modal correctly rendered in the test:

Mr.portal, I wanted to see you for ages!

Why baseElement instead of screen

But why do we need to use baseElement?

When you use screen, it only looks inside the subcomponents of a component passed to render function. In my example, it looks into <App/> and its children but not what sits outside <App/> component.

On the other hand, baseElement points to the entire rendered components, which include <App/> and modals that are rendered in a portal.

That is why the test failed with screen but succeeded with baseElement.

Caution

There are other ways to render a modal in React applications and each method requires different approaches to test the modal component.

So it is always important to be aware of where and how the modal you are testing is rendered and tailor your test accordingly!

Conclusion

Knowing how to test components rendered in portals is definitely useful given that many applications have designs where important user interactions take place within these components.

Thanks for reading this article.

See ya!

Persisting state on page refresh in React/Redux app

mihomihouk — Mon, 10 Jul 2023 10:09:36 +0000

Introduction

Refreshing a page is a common behaviour for app users. However, when using Redux, the state stored in the Redux store is reset on page refresh. This can be problematic for apps with protected routes, as users may be redirected to the login page even if they were previously authenticated.

In this article, we will explore several solutions, including session/local storage and Redux Persist, as well as their limitations to create a more user-friendly experience!

Problem

Consider the following example of a protected route:

import { useLocation, Navigate } from 'react-router-dom';
import { useAppSelector } from '../hooks/hooks';
import React from 'react';
import { LOG_IN_PATH } from './routes';

interface SecureRouteProps {
  children?: React.ReactNode;
}
export const SecureRoute: React.FC<SecureRouteProps> = ({ children }) => {
  const location = useLocation();
  const { isAuthenticated } = useAppSelector((state) => state.auth);

  if (!isAuthenticated) {
    return <Navigate to={LOG_IN_PATH} state={{ from: location }} replace />;
  }

  return <>{children}</>;
};

The problem occurs when the user refreshes the page, causing the isAuthenticated state to revert to its initial value, leading to an unnecessary redirect to the login page.

This can be very frustrating for users as they have already been signed in. How can we avoid this unnecessary redirection while ensuring our pages are protected from unauthenticated users?

Common solutions

There are several solutions to prevent this unnecessary redirection on page refresh. One approach involves using session/local storage in combination with Redux.

In this approach, we need to write some additional code to add, read and remove a certain item from sessionStorage or localStorage alongside updating Redux.

Use session storage + Redux

If I implement this in my project, the change would look like this:

Store the authentication status in session storage after successful login:

sessionStorage.setItem('isAuthenticated', 'true');

In the protected route component, check the authentication status by getting the state stored in session storage. Then, if the user is not authenticated, redirect them to the login page:

export const SecureRoute: React.FC<SecureRouteProps> = ({ children }) => {
  const { pathname } = useLocation();
  const isAuthenticated = sessionStorage.getItem('isAuthenticated') === 'true';

  if (!isAuthenticated) {
    const redirect = encodeURIComponent(pathname);
    return (
      <Navigate
        to={{
          pathname: '/login',
          state: { from: redirect },
        }}
      />
    );
  }

  return <>{children}</>;
};

And finally, clear the stored authentication status on logout.

sessionStorage.removeItem('isAuthenticated');

Use local storage + Redux

The second approach is to use local storage and this is very similar to the first approach.

The code is almost identical. We just need to replace the sessionStorage in the example above with localStorage (e.g., const isAuthenticated = localStorage.getItem('isAuthenticated') === 'true';).

The major difference between using session storage and local storage is the duration of the state persistence. While the state stored in session storage gets reset once the tab closes, local storage allows the state to persist even if the user closes and reopens the browser.

These are already great solutions. However, one drawback of using session/local storage directly with Redux is that it requires adding additional code to every place where the state needs to be persisted. This can increase the complexity of the code and make it more susceptible to unexpected errors.

So I took a simpler and optimised approach: using Redux Persist.

Redux Persist

Redux Persist is a library designed to allow applications to preserve their state even on page refresh.

It is really easy to incorporate Redux Persist in our existing React/Redux app. The only thing we need to do is to make a small modification to the store and insert a wrapper provided by Redux Persist in a higher component. Doing so eliminates the need to add additional state updates in multiple pages/components.

How to integrate Redux Persist

Let's look at how I updated my code to use Redux Persist.

Install the Redux Persist library:

npm install redux-persist

Update store config

Next, following their official document, I added some changes to my store.

Before:

import { PreloadedState, configureStore } from '@reduxjs/toolkit';
import modalReducer from '../slices/modals-slice';
import postReducer from '../slices/posts-slice';
import authReducer from '../slices/auth-slice';
import userProfileReducer from '../slices/user-profile-slice';

export const store = configureStore({
  reducer: {
    modals: modalReducer,
    posts: postReducer,
    auth: authReducer,
    userProfile: userProfileReducer
  }
});
export const setupStore = (preloadedState?: PreloadedState<RootState>) => {
  return store;
};

export const createPreloadedState = (
  customState: Partial<RootState>
): PreloadedState<RootState> => {
  return {
    modals: { ...store.getState().modals, ...customState.modals },
    posts: { ...store.getState().posts, ...customState.posts },
    auth: { ...store.getState().auth, ...customState.auth },
    userProfile: { ...store.getState().userProfile, ...customState.userProfile }
  };
};
export type AppDispatch = typeof store.dispatch;
export type AppStore = ReturnType<typeof setupStore>;
export type RootState = ReturnType<typeof store.getState>;

After:

import {
  PreloadedState,
  combineReducers,
  configureStore
} from '@reduxjs/toolkit';
import modalReducer from '../slices/modals-slice';
import postReducer from '../slices/posts-slice';
import authReducer from '../slices/auth-slice';
import userProfileReducer from '../slices/user-profile-slice';
import storage from 'redux-persist/lib/storage';
import { persistReducer, persistStore } from 'redux-persist';
import autoMergeLevel2 from 'redux-persist/es/stateReconciler/autoMergeLevel2';

const persistConfig = {
  key: 'root',
  storage,
  stateReconciler: autoMergeLevel2
};

const rootReducer = combineReducers({
  modals: modalReducer,
  posts: postReducer,
  auth: authReducer,
  userProfile: userProfileReducer
});

const persistedReducer = persistReducer<ReturnType<typeof rootReducer>>(
  persistConfig,
  rootReducer
);

export const store = configureStore({
  reducer: persistedReducer
});

export const persistor = persistStore(store);

export const setupStore = (preloadedState?: PreloadedState<RootState>) => {
  return store;
};

export const createPreloadedState = (
  customState: Partial<RootState>
): PreloadedState<RootState> => {
  return {
    modals: { ...store.getState().modals, ...customState.modals },
    posts: { ...store.getState().posts, ...customState.posts },
    auth: { ...store.getState().auth, ...customState.auth },
    userProfile: { ...store.getState().userProfile, ...customState.userProfile }
  };
};
export type AppDispatch = typeof store.dispatch;
export type AppStore = ReturnType<typeof setupStore>;
export type RootState = ReturnType<typeof store.getState>;

Let me briefly explain a few important points:

storage

const persistConfig = {
  key: 'root',
  storage,
  stateReconciler: autoMergeLevel2
};

Here storage is shorthand for storage: storage, meaning I chose localStorage to store the persisted state. You could choose sessionStorage and write storage: storageSession instead.

stateReconciler

In the same object, we also see this somewhat unfamiliar property: stateReconciler. This is where we choose how to merge persisted state with the initial Redux state. This is set to autoMergeLevel1 by default but we can pass autoMergeLevel2 or hardSet as well. hardset completely overrides the initial state in our reducer. On the other hand, both autoMergeLevel1 and autoMergeLevel2 allow the initial state to be merged with the persisted state with slightly different behaviour: autoMergeLevel1 only concerns top-level property values while autoMergeLevel2 merges two levels deep.

To understand more about these differences, I highly recommend you to read this article.

Wrap root components with PersistGate

In order to ensure that UI gets rendered only after the persisted state has been retrieved and saved to Redux, we also need to add PersistGate to our root component.

import React from 'react';
import ReactDOM from 'react-dom/client';
import { BrowserRouter } from 'react-router-dom';
import { Provider } from 'react-redux';
import { persistor, store } from './store/store';
import App from './App';
import { disableReactDevTools } from '@fvilers/disable-react-devtools';
import { PersistGate } from 'redux-persist/integration/react';
import { MainLoader } from './components/main-loader';

if (process.env.NODE_ENV === 'production') disableReactDevTools();

const root = ReactDOM.createRoot(
  document.getElementById('root') as HTMLElement
);
root.render(
  <React.StrictMode>
    <Provider store={store}>
      <PersistGate loading={<MainLoader />} persistor={persistor}>
        <BrowserRouter>
          <App />
        </BrowserRouter>
      </PersistGate>
    </Provider>
  </React.StrictMode>
);

We could pass a customised loading component to the loading prop inside PersistGate.

This is it!
After these few changes, I could see refreshing a page no longer redirect users to the login page. The state still persists after closing the browser too, allowing us to access the app again without going through the login process.

Limitation

It's important to note that persisting sensitive data, such as access tokens or user IDs, in local or session storage can introduce security vulnerabilities, particularly cross-site scripting (XSS) attacks. These approaches might offer improved user experience by maintaining user state across page refreshes, but they can also expose sensitive information to malicious actors.

When sensitive data is stored in client-side storage, it becomes accessible to JavaScript code running in the user's browser. If an attacker manages to inject malicious code into your application through XSS, they can retrieve and misuse the stored data, compromising user security.

I will explore more secure approaches to this in my future article.

Conclusion

Redirecting users to the login page on every reload can lead to a poor user experience. This could be overcome by using session/local storage. Redux Persist simplifies this process by automatically persisting and rehydrating your Redux state.

However, it is very important to be aware of the security implications of storing data in local/session storage to protect users from malicious attacks.

Deploy your full stack React & Node.js app

mihomihouk — Mon, 03 Jul 2023 18:04:41 +0000

Are you ready to take your full-stack application from development to production but unsure of the necessary steps and potential pitfalls along the way? Deploying a full-stack application requires careful planning and consideration to ensure a smooth transition and a successful launch. Last month, I deployed my application and it took me a week until I finally saw it running perfectly in production.

In this article, I will share with you the small and big mistakes I made and points to bear in mind in order to successfully deploy your full-stack application. From understanding the build command and customising it for your project to selecting a hosting service and setting up a production database, we will cover key aspects that can make or break your deployment.

Understand build

Let's understand what the build command means before deploying your application. You can skip this part if you are already comfortable with the concept and what it actually means to our deployment.

Basically, we need to run build command to make our files deployable. This command creates a build folder in the root of our application and stores optimised files, including static resources, css, html, JavaScript files, used in your application inside this folder. The content of the folder gets updated if changes are added to these files.

Customise build command for your project

The build command, like other scripts, can be customised in package.json. What should be included here totally depends on your project. For example, you might need to include logic to convert TypeScript code to JavaScript code if you are using TypeScript.

While it may seem arbitrary, it is very important to include all the steps required for your particular project in this command; otherwise, you might encounter some errors in deployment. So let's take a little moment, search for what you should include, and customise your build command.

The frontend build script in my recent project looks like this:

"build": "tsc && react-scripts build"

And this is its backend script:

"build": "tsc && prisma generate && prisma migrate deploy"

Let me explain these scripts.

Compile TypeScript into JavaScript

If you are using TypeScript in your project, please do not forget to include tsc in your build command. This command converts all TypeScript codes into JavaScript codes, making your files executable in production.

Set up access to the database in production

In my project, I am using a combination of Prisma and PostgreSQL to manage its database. The second command, prisma generate, generates Prisma Client, which allows me to interact with my database to implement CRUD operations (e.g., creating a new item in a table). The third command, prisma migrate deploy, on the other hand, applies new structural modifications (e.g., adding a new table) to my database.

As you can see, what should be included in your build scripts really depends on which technologies you are using and how you manage your codebase and database.

Deploy with a hosting service

I used Render to deploy my application. Render is one of the most popular web hosting services today. It is really easy to set up, and we can use the basic service for free.

To give you an overview, I set up my hosted client as "static site", my hosted server as "web service", and created a PostgreSQL database for production on Render.

My dashboard looks like this:

Set up the client

First, I set up my client hosting following their documentation for a Create React App.

In the process, they ask me to add values to "Build Command" and "Publish Directory." Now that we know what the build command is, the instruction should be straightforward.

I did not fully understand the build command when I initially set it up, and I excluded some critical implementations from the script. I hope you will not make the same mistake as me!

Then, in the "Custom Domains" section, I set up a custom domain so I can use my unique domain purchased from Namecheap instead of the default Render domain (e.g., yourstaticsitename.onrender.com). You can find out how to set it up via this link.

Once I saved the settings, I filled out all the environment variables used in my client.

Set up backend

Next, I set up web service following their documentation for deploying a Node Express App.

You might get confused when setting up the "Buid& Deploy" section.

First confusion might come from "Build Command." The example in the instruction uses just yarn as its "Build Command."

Yes, this yarn command installs all the libraries required for the server and we definitely need to run this to deploy our server. However, as I explained at the beginning of this article, build command should include more logic than this if we are using TypeScript and/or need migration for our database.

Thus, I added this value to "Build Command":

Secondly, instead of "Publish directory" that we saw when setting up a static site, we are asked to add "Start Command" value.

This is because we need to START our server to handle requests from our client. And this command runs only after build command runs.

So in my package.json, I created my start script like this:

 "start": "node ./build/src/index.js"

node executes JavaScript code stored in the build folder. It is important to double-check the location of built main JS file in your project and write the right path to the file. The file could be named app.js or index.js depending on your project.

Then I again set up a custom domain for the server and set environment variables as I did for the static site.

Ensure the client and server are related subdomains

If you do not use cookies, please skip this section.
But if you do, this is really important.

I am using cookies to authenticate users in my application. In short, when a user logs in, my server issues an access token and passes it to the client via cookies. Then, the client's token is checked on the server every time the client makes a request.

This exchange via cookies is only possible when they are sharing the same root domain. For example:

www.rootdomain.com and api.rootdomain.com can exchange cookies.
But www.rootdomain.com and api.differentdomain.com cannot exchange cookies.

If you run your application in production and see no cookies in Developer tools, it might be because of this domain restriction.

For those who want to see more examples like this, please check out this video.

Create a production database

After all of these setups, I was still failing to connect my server with the client.

And I finally learned that I need to make my database accessible by my server in production!

PostgreSQL database has a "connection URL", a URL that the application server uses to connect to the database. The connection URL looks like this:

user@localhost:5433/mydb?options=-c%20synchronous_commit%3Doff

As explained in this documentation, localhost:5433 points to a port. And this was the port set up by PostgreSQL by default and I continued using this default port in production.

In fact, this was the very cause of my problem.
This "local" database is only accessible from the application running on the same machine, meaning it is impossible for the deployed server to make a connection with it.

So what did I do?

There were two options to overcome this:

Build a production database and use it both from the development and production environment.
Build a production database and use it only in production.

In web development, the second option is regarded as better since having a separate database can protect valuable information from accidental modifications and
unauthorised access.

Fortunately, Render has a great service with which we can create a hosted production PostgreSQL database.

Its set-up is not as complicated as it seems but there are several things to bear in mind:

The web service and database should be in the same region.
Dynamically pass the database URL to your server so that the server can connect the local database in development and the hosted database in production.

It might be a good idea to look at the database hosting services when choosing a provider to deploy your application.

Conclusion

That's it!

As we have seen, deploying a full-stack application involves several crucial steps that require good knowledge of the technologies used in the application and our decision-making. By customising the build command, setting up hosting services, and ensuring proper database configuration, you can successfully deploy your application in a production environment.

Thank you so much for reading this article if you made it this far! Whether you are about to start deploying your application or experiencing problems in deployment, I hope it could offer you some ideas.

Happy deploying!

“Timed out” error in React/Redux app test: This is how I found my solution

mihomihouk — Fri, 23 Jun 2023 15:47:09 +0000

Introduction

Testing is an integral part of software development, ensuring that our applications function as intended and deliver a reliable user experience. But testing React applications, especially when dealing with asynchronous operations and state changes, can be a bit tricky. In this article, we'll dive into a challenge I recently encountered during React testing: handling "Timed out" errors when waiting for asynchronous elements to appear.

What I wanted to test

I'm developing a React app (created with create-react-app) with Redux. I was trying to test one of the components using react-testing-library and Jest to ensure it renders the two elements below on visiting the dashboard:

First, loading spinner
Second, fetched list of posts

My Initial test code

Here is the test I wrote.

describe('PostList', () => {
  it('should render a post list data after loading', async () => {
    renderWithProviders(<PostList />);
    const loadingEl = await waitFor(() => screen.findByTestId('main loader'));
    expect(loadingEl).toBeInTheDocument();
    const postEl = await waitFor(() => screen.findByText('test'));
    expect(postEl).toBeInTheDocument();
  });
});

The overview of the testing steps is:

1.Render the component

 renderWithProviders(<PostList />);

This renderWithProviders is a reusable custom render function that wraps components with Redux providers. Please visit this link if you want to learn more about it.

2.Ensure loading spinner appears

const loadingEl = await waitFor(() => screen.findByTestId('main loader'));
expect(loadingEl).toBeInTheDocument();

I set a testId for the loading spinner, which appears immediately after asynchronous operation starts like so:

const override: CSSProperties = {
  display: "block",
  margin: "0 auto",
  borderColor: "red"
};

export const MainLoader = () => {
  return (
    <div className="w-full h-full flex items-center" data-testid="main loader">
      <PropagateLoader
        size={30}
        cssOverride={override}
        aria-label="Loading Spinner"
      />
    </div>
  );
};

3.Ensure post

const postEl = await waitFor(() => screen.findByText('test'));
 expect(postEl).toBeInTheDocument()

I use Mock service worker (msw) to intercept API call. This “test” is one value of mocked data. The mocked data returned instead of actual data via a handler when GET request is called.

export const mockPostItem1: Post = {
  id: "123",
  author: mockUser,
  caption: "test",
  createdAt: "2023-06-19T15:30:00Z",
  files: [
    {
      id: "123",
      fileName: "Vegetable garden",
      size: "60b170c0-7673-46c4-a71d-861845ae9097",
      mimetype: "image/jpeg",
      alt: "Vegetable garden",
      portraitFileKey:
        "b269db9743e39238bb1babce7e70fb0db134f45dc222efac56e324016b764xxx",
      squareFileKey:
        "adked8886bd2f14f824914e5e87387136471a4aaf630f1073bcdg7cba",
      portraitFileUrl: "/image/mock-post-image.png?"
    }
  ],
  totalLikes: 5,
  comments: [],
  totalComments: 7,
  updatedAt: "2023-06-19T15:30:00Z"
};

import { rest } from "msw";
import config from "../config";
import { mockPostItem1 } from "./posts";
import { mockUser } from "./user";

const baseURL = config.apiUrl;

export const handlers = [
  rest.get(`${baseURL}/auth/${mockUser.id}`, (req, res, ctx) => {
    return res(
      ctx.status(200),
      ctx.json({ data: { user: mockUser, posts: mockPostItem1 } })
    );
  })
];

So if the fetching is successful, the text “test” should appear in the DOM.

Error Message

When I ran the test, the elements (spinner and fetched data) never appeared. My console showed this error:

● PostList › should render a post list data after loading

    Timed out in waitFor.

      157 |   it('should render a post list data after loading', async () => {
      158 |     renderWithProviders(<PostList />);
    > 159 |     const loadingEl = await waitFor(() => screen.findByTestId('main loader'));
          |                                    ^
      160 |     expect(loadingEl).toBeInTheDocument();
      161 |     const postEl = await waitFor(() => screen.findByText('test'));
      162 |     expect(postEl).toBeInTheDocument();

      at waitForWrapper (node_modules/@testing-library/dom/dist/wait-for.js:166:27)
      at Object.<anonymous> (src/container/post-list.test.tsx:159:36)

What does it mean!?

The "Timed out in waitFor" error message typically occurs when using the waitFor function. It indicates that the specified condition being waited for did not occur within the designated timeout period (in this case default timeout of 1,000 milliseconds).

And as you can see below, the DOM was showing the default UI that I prepared for the case when there’s no post list instead of a mocked post list:

<div
  class="flex justify-center items-center h-screen"
>
  <div
    class="text-center"
  >
    <h3
      class="text-3xl font-bold mb-4"
    >
      No posts yet
    </h3>
    <p
      class="text-lg mb-6"
    >
      Create a new post to get started.
    </p>
    <button
      class="w-full bg-primary-500 text-white inline-block p-2 rounded-lg hover:bg-opacity-75"
      tabindex="0"
      type="button"
    >
      Create Post
    </button>
  </div>
</div>

So what basically the error tells us is that the expected data is not appearing within 1 second.

Narrowing scope

So I could know somehow the expected data is not rendered in the DOM within the timeout.

Yes, this is a very vague error...

So to start, I asked myself several questions:

Is state change handled properly in this specific test?
Is simply asynchronous transaction taking too much time?
Is api URL in my handler set correctly?
Are the versions of packages used in the test compatible to each other?

In answering the questions above, I then tried to:

1.Add timeout to asynchronous operations

One possibility of the cause of the error was the asynchronous operation was simply taking long time. If that’s the case, the error could be solved by extending timeout like so:

describe('PostList', () => {
  it('should render a post list data after loading', async () => {
    renderWithProviders(<PostList />);
    const loadingEl = await waitFor(() => screen.findByTestId('main loader'), {timeout: 3000});  // Set a specific time here
    expect(loadingEl).toBeInTheDocument();
    const postEl = await waitFor(() => screen.findByText('test'));
    expect(postEl).toBeInTheDocument();
  });
});

In theory, by adding timeout, the test now waits a bit longer until the loading spinner appears.

2.Store env variable used in API call locally

Another possibility I thought of was API URL. In my app, I'm storing all env variables including API URL in Doppler and I was running test codes without using any env file. I thought somehow the env variables are not accessible when running tests, and thus test might have failed.

3.Change package versions

I also changed the versions of axios and msw as I’d seen some reports on interception errors due to the compatibility between the two packages.

4.Investigate `renderWithProvider`

Moreover, I revisited my code that handles state change in testing mode making sure there is no typo or misconfiguration.

5.Check other API call

Just to double check this is not the problem of state handling, I wrote another test for different components that also uses API call. It actually threw the same error.

After all these attempts, I still could not see any progress in my test!

The problem could be my set up of Redux, mws, or my testing code…

Yes…
I completely ran out of ideas!

Reaching out to communities

I’ve tried my best and still had no luck.
So this is the time to ask others for help!

1.Stack Overflow

I’ve first reached out to stack overflow. I prepared a document where I explained what I want to achieve, the error I’ve seen and what I tried to solve it.

Unfortunately I didn’t get any response from other members.

But this process actually helped me come up with other possibilities and organise my understanding about the problem.

2.Testing channel in Reactiflux Discord community

Out of desperation, I asked for help in a Discord community dedicated to React. I’d never posted anything in this community before but I’ve seen people helping each other very actively!

Surprisingly, a very kind person responded my post in a matter of one hour after I posted my issue, diving into my code, giving me really great tips!

And yes! With his insights, I could finally find solutions, which I’d like to share in the next section.

Culprit

So what was the problem?

First, let’s take a look at my final working test code.

describe("PostList", () => {

    it("should render a post list data after loading", async () => {

    const store = setupStore();

    store.dispatch(setUser(mockUser));

    store.dispatch(setIsAuthenticated(true));

    renderWithProviders(<PostList />, {store});

    await waitForElementToBeRemoved(() => screen.queryByTestId("main loader"));

    const postEl = await screen.findByText("test");

    expect(postEl).toBeInTheDocument();

    });

});

As you may notice, I added a number of changes to this test.

1.Redux state change

One of the main issue was that the function that runs API call never ran. It runs only when there is a user but in the test, the user state was undefined.

React.useEffect(() => {
    let isMounted = true;

    const fetchData = async () => {
      try {
        setIsLoading(true);
        if (user) {.     //If user is undefined, the code below never runs!!!
          const { data, alertMessage, isSuccess } = await getAllPosts(user.id);
          if (!isSuccess) {
            if (alertMessage === "Unauthorised") {
              navigate(LOG_IN_PATH);
            }
            alert(alertMessage);
            setIsLoading(false);
            return;
          }
          if (isMounted) {
            dispatch(updatePosts(data));
          }
        } else {
          navigate(LOG_IN_PATH);
        }
        setIsLoading(false);
      } catch (error) {
        console.log(error);
        alert("We failed to get information of posts.");
      }
    };
    fetchData();
    return () => {
      isMounted = false;
    };
  }, []);

This is because in my app:

User logins and user information is immediately stored in Redux
Using the user information, a list of posts including user’s posts is fetched

So the solution was easy. I just needed to ensure user state gets updated with mockedUser BEFORE running the test (= a list of posts gets fetched).

const store = setupStore();

store.dispatch(setUser(mockUser)); // Update user

store.dispatch(setIsAuthenticated(true)); // Update auth state

renderWithProviders(<PostList />, {store}); // Pass the state to redux provider

2.First wait until loading indicator to be REMOVED

In web applications, it’s a very common practice to render loading UI while fetching data. When testing asynchronous operations, we should ensure loading state is completely removed before searching for the elements we expected to be in the DOM.

Before:

const loadingEl = await waitFor(() => screen.findByTestId('main loader'));
expect(loadingEl).toBeInTheDocument();
const postEl = await waitFor(() => screen.findByText('test'));
expect(postEl).toBeInTheDocument();

In my previous code, I used findByTestId to handle loading spinner. This might lead to an error as findByTestId returns a promise that resolves when it finds matching id but there is no guarantee that an element with the id is removed from the DOM before the fetched post list appears.

After:

await waitForElementToBeRemoved(() => screen.queryByTestId("main loader"));

const postEl = await screen.findByText("test");

expect(postEl).toBeInTheDocument();

On the other hand, waitForElementToBeRemoved explicitly waits for an element to be removed from the DOM. So waitForElementToBeRemoved is more appropriate to test a loading UI and the final fetched data.

waitFor or findBy?

You may notice I also changed my code to use only findByTestId and findByText instead of using them with waitFor to test asynchronous operations.

While it seems not a bad practice to use waitFor in this scenario, findBy itself just does the job and it improves the code readability.

3.Returned json object

After finding the two solutions, I could see the loading spinner rendered in the DOM.

It was progress.

But I still failed to see the fetched post list and here is the final mistake that I found in my test code:

rest.get(${baseURL}/post/get-posts, (req, res, ctx) => {
    return res(ctx.json({data: [mockPostItem1, mockPostItem2]}));
  }),

This is mocked API call I set up using msw.

Note that the object inside ctx.json( )assumes fetched data belongs data property, which is slightly different from data structure dealt in my client code.

So I corrected the code like so:

rest.get(${baseURL}/post/get-posts, (req, res, ctx) => {
    return res(ctx.json([mockPostItem1, mockPostItem2]));
 })

After implementing the necessary changes and addressing the issues I encountered, I was happy to see my test finally pass without any errors.

I hope that by sharing my experience of trial and error and the solutions I found, this article can help others who might encounter similar challenges in testing react apps.

Fight for Landing a Dev Job: What I Learned by Attending a React.js Meetup

mihomihouk — Fri, 09 Jun 2023 12:26:21 +0000

Introduction:

In the competitive field of software development, securing a job as a developer can feel like a battle. I am a Junior full stack developer based in the UK with expertise in React, Typescript and Node. Since being made redundant at my previous company in March 2022, I’ve been on job hunt. In this article, I want to share my personal experience and the valuable insights I gained from attending a tech meetup, React.js Girls, as a job seeker.

What is React.js Girls:

React.js Girls is a meetup event that features female speakers sharing their knowledge and experiences with React. Although the speakers are women, anyone can attend it as its audience regardless of gender.

I was fortunate to secure a ticket to attend at the last minute. I learned about the event just a few days before the event day and found that all the seats were already taken. But I added myself to the waiting list in case of any cancellation. To my surprise, I received an email from the organiser on the afternoon of the event day, granting me a spot!

The event took place in central London, starting from 6.45pm. They provide us pizza, snacks and drinks for free, which not only made it easier to strike up conversations with other attendees but also allowed me to focus on the talks without being distracted by hunger.

We had three speakers covering topics such as React-testing-libraries/Jest, alternative React state management, and creating iInclusive workplace. While all the talks were inspiring and definitely worth digging into, I’d like to focus on what I, as a job seeker, learned from my first tech meetup experience. If you are interested in the talks, please find their recording on YouTube (As of 9 June, they haven’t uploaded the recording yet. But I’m sure they will!).

What follows are the takeaways from the event!

1. The power of meeting real people:

It is a cliche but meetup is indeed good for networking. Well, in my case, it was good to learn how to engage with fellow developers. While I couldn’t make extensive connections due to time limitations, I had meaningful conversations about their career paths, opinions about remote working, technologies in use, and projects they are involved in. These conversations were not solely focused on professional topics; we also discussed cultural experiences, travel and future plans. I personally believe this is the true power of meetups - the ability to build connections and relationships by sharing our views on broader topics as humans, spending time together in the same space, and engaging in face-to-face conversations. In this respect, meetups offer a different networking experience compared to social online platforms.

2. Reflecting on my practices and learn from senior developers:

During the months of my job hunt, working on my personal portfolio project or learning new technologies left me feeling uncertain about my skills and knowledge. Attending the meetup allowed me to compare my own project experiences and learn from the practices and solutions shared by senior developers. Finding similarities in the challenges, solutions and the underlying logic between me and the speakers gave me assurance and confidence in my skills. I also learned new concepts, decision-making tips for testing, insights about a new state management framework and how it can be compared with Redux, and how to restructure our understanding of inclusivity to foster it in our team. The talks were based on real experiences, making the learnings highly adaptable and practical.

3. What didn’t happen:

Although I had some hope to get feedback on my project and advice for job hunting or career development, they did not happen in this event. Apparently, this meetup was not specifically focused on those aspects and I paid extra attention to what other people wanted to talk about rather than seeking help for myself. But you never know if someone in the meetup might be willing to offer assistance on the spot. So it might be worth preparing to show projects, CV and questions in case such opportunities arise!

Conclusion:

Attending a tech meetup could be intimidating or it may seem inconsequential if you’ve never experienced one before. But to me, it was a great experience in my quest for a dev job. Meeting like-minded people, gaining access to industry expertise, and assessing my current skills and knowledge had a positive impact on my motivation, connections and tech skills.

Thanks for reading this article! If you have an open role at your organisation, please do let me know via my linkedIn.

A Solution: How to successfully fetch data from Firestore Database

mihomihouk — Sun, 27 Mar 2022 21:27:49 +0000

When trying to fetch a set of data from Firestore Database, I stumbled into a pretty basic challenge: the data is not shown on the screen.

This article suggests a solution for those who are learning Firebase and got caught by a similar problem.

What was the Situation?

When I was learning how to use Firebase V9 with a Udemy course, I was struggling to get the data that I manually created on Cloud Firestore.

I went through all the following processes twice just to make sure I don’t miss any essential steps to successfully fetch the data into my browser.

Create a Firebase Project
Create a web app under the project
Copy the config and paste on a file in my local project
Initialise firebase in the file using the copied config
Initialise firestore and export the particular database from the file
Install the latest firebase
Run the application at localhost:3000

Problem

No error message, all seems fine except that no data from the database was shown in the place that it should be.

Solution

Did All The Process Again

Scraping the project to the bin, I downloaded the course file again, wrote the code again by watching the course video very carefully, and made sure that I didn't miss any step.

Checked if My Code Looks Exactly the Same as the Tutorial

No typo and no mistake. It’s impossible to be wrong.

Solution: Firebase Rules

If my code is perfect, then the problem should be on the side of firebase.

And here it is, the rules were written as below:

The 'if false' part was the cause of the problem.

If the part is false, no one can read and write the data.

For the sake of experimenting with data-fetching for this tutorial, I temporarily edited the sentence to 'allow read, write: if true'.

And now on the screen, I can see the data that I manually added on Firestore Database. This means the data is successfully fetched.

Please note that this is a bad practice if you’re actually developing an app with personal information as it allows any person can access and change the contents.

But if you’re just a beginner wanting to understand some basic functions of firebase and haven’t learned about the firebase rules yet, this could be a temporary solution.

You can always come back and modify the rules as you go.

The reasons why beginners should join an experiential team development project before applying for a job.

mihomihouk — Mon, 21 Mar 2022 23:55:19 +0000

Have you ever thought that you have been practising coding alone for so long but there still seems to be a huge gap between your current self and a strong candidate for job hunting?

If you are unsure about your preparedness and current skill, joining an experiential team development is definitely worth investing time.

Here I will share my own experience of developing an application with other peer code learners and takeaway from being part of a team.

Why did I decide to join?

The event that led to me joining an experiential team development was quite simple: my mentor’s recommendation. Ever since I started to learn how to code, I had used a mentoring service through which I got monthly mentoring about my progress and technical advice from developers. But I have spent most of my time learning alone by using online tutorials and creating small apps to try out new skills. I was always feeling anxious about applying for a job without actually knowing how to develop an app in collaboration with other people.

And one day, my mentor asked me to take part in a team development event that he hosted. At that time, I was nowhere near confident about my code. I had just finished 70% of my first big challenge, creating a Todo app with Next.js and React. But I kept asking myself, ‘When will the best timing come then?’ And my answer is ‘It will never come. I have basic skills so I should just jump into it!’ So I did it.

What were my expectations for team development?

There were two main expectations in participating in the team development.

Understanding what issues would emerge in terms of communication within the team and my own skills, and how I should deal with them in team development.

Getting a clearer idea on what are the gaps between a strong candidate for frontend engineer and what skills from the perspective of team development, and what kind of knowledge I should learn to close these gaps.

As written below, my takeaways from experiential team development turned out to be far richer than my initial expectation.

What did we create?

Here is the finished product that 8 of us all made together.

https://todo-team-2-qigd0p0al-m8na.vercel.app/

In this development, Next.js & React were used as the main framework and library while Recoil was introduced for state management. In addition, Chakra-UI was used as the framework for styling.

Languages/frameworks and other technologies used in the application

Next.js
React
Recoil
Chakra-UI
Functions implemented in the application
Add, edit, view details, delete
Comment
Markdown
Pagination
Scrolling
Change Progress
Change Priority
Search
Filters

What did we try as a team?

Page transitions using Next.js routing
Global state management using Recoil
Layout creation using Chakra-UI
Propose a feature or issue you would like to work on
Resolving problems when errors occur
Purpose/Background of Team Development
Experience in team development, learning how to use Github, etc.
Learning how to implement basic application functions by creating a todo list
Learn how to write code that is easy to understand by others through code writing and code reviews based on the premise of team development

What was my role in the team development?

From early on in the development process, I was in charge of coordinating the schedule and agenda for the weekly meetings, as well as hosting the weekly online meetings. I also actively reviewed code as needed, helped other members dealing with errors, and managed the progress of the development.

What were some of the things we tried as a team?

While we started off as strangers, we all learned to maintain smooth communication as time went by. Since app development involves a lot of individual work, it is necessary to make it easy for all members to know what each person is working on, and how much progress he or she is making. For this reason, we tried to create an atmosphere in which the entire team could easily ask for help from each other by clearly assigning responsibilities, and exchanging messages frequently.

What were some of the difficulties in team development?

Especially for a while after the development started, I was scared of operating git. As we were developing as a team, I was worried too much about making mistakes, thinking 'What if this operation damages the entire application?' However, my mentor kept telling us 'Errors and failures are opportunities to learn. It would be rather strange if everything is perfect from the beginning.'Also, I soon learned that other team members felt the same way. Thanks to the advice and learning, my anxiety quickly disappeared.

What are my impressions of participating in team development?

First of all, from a technical standpoint, I was able to learn many frameworks and implementations that I had no experience with, and through code reviews, I was able to see the code that other members wrote, which greatly improved my knowledge and skills.

The below are some of the things I found unique to team development, and therefore have given me a great deal of confidence in my job hunting.

Branch creation
Creating pull requests on GitHub
Code review
Issue creation on GitHub
Utilising the project function on GitHub
Moving to a branch created by another member for code review
Conflict resolution

Next, regarding the software side, I learned the importance of progress management, MTG, and detailed (but not too detailed) communication among team members. I was also able to rediscover new possibilities and skills in my role as a leader during the course of the program.

Finally, this team development also had an enormous impact on my own motivation. Over the period of self-learning, I had been feeling a bit stuck not knowing if the code I wrote was correct or not and whether I was on the right track in becoming a skilful frontend engineer. Engaging with other code learners through application development, in this respect, was of great encouragement as we could share the same difficulties and look for the solutions together.

Comments from other members (excerpts)

I was able to improve my knowledge by learning that there are many different ways to achieve the same thing, and by learning things I didn't know.
Having team members who get together every weekend to exchange opinions and communicate with each other has boosted my motivation, and I think it has been a very valuable experience.
By being involved in team development, I was made aware once again of my weaknesses other than technical aspects.

For those considering experiential team development

If you are stuck in self-study, I definitely encourage you to participate in some events as well as the one-on-one meetings about code-learning and future career. Team development is one of them, and it will bring you valuable experience that you cannot get from self-study.

DEV Community: mihomihouk

How to be a web accessibility practitioner in two days

Introduction

Day 1: Learn about accessibility

Understand the background

Understand the accessibility level of our website/application

Learn the solutions and make your Accessible checklist

Learn from real-world examples of accessibility

Iterate your accessible checklist

Day 2: Apply accessibility to your project

Use tools as your guide

Other useful tools

Colour contrast

HTML Outline

Example: how my application changed after accessibility improvements

Conclusion

How to make a reusable button component with Typescript in React applications

Introduction

Cluttered button component

Refactor a reusable component using JSX.IntrinsicElements

Change the type of the props

Adjust the way to destructure and use props

Final remark

Testing React Portals: A Real-Life Example for testing a modal

Introduction

What is portal and when to use it

Custom modal as an example

Test modal

What I wanted to test

Testing strategy

Initial code (don't do this)

Final code (definitely try this!)

Why baseElement instead of screen

Caution

Conclusion

Persisting state on page refresh in React/Redux app

Introduction

Problem

Common solutions

Use session storage + Redux

Use local storage + Redux

Redux Persist

How to integrate Redux Persist

Update store config

Wrap root components with PersistGate

Limitation

Conclusion

Deploy your full stack React & Node.js app

Understand build

Customise build command for your project

Compile TypeScript into JavaScript

Set up access to the database in production

Deploy with a hosting service

Set up the client

Set up backend

Ensure the client and server are related subdomains

Create a production database

Conclusion

“Timed out” error in React/Redux app test: This is how I found my solution

Introduction

What I wanted to test

My Initial test code

Error Message

What does it mean!?

Narrowing scope

1.Add timeout to asynchronous operations

2.Store env variable used in API call locally

3.Change package versions

4.Investigate renderWithProvider

5.Check other API call

Reaching out to communities

1.Stack Overflow

2.Testing channel in Reactiflux Discord community

Culprit

1.Redux state change

2.First wait until loading indicator to be REMOVED

Before:

After:

waitFor or findBy?

3.Returned json object

4.Investigate `renderWithProvider`