DEV Community: Pankaj Patel

Too many useState? Let's useReducer!

Pankaj Patel — Tue, 28 Mar 2023 12:42:58 +0000

Modern Frontend is similar to good old web development, but with one catch: the page in the browser is as sophisticated as the backend.

Since we learned to load things asynchronously, we want to keep the user as productive as possible and not show any loading screen. This means that the Website became THE WebApp.

And the most common thing in any WebApp is state management.

All this prologue was to answer one question: "Why do we have a state in the Frontend Application?"

This post will examine better state management in our favourite library, React.

As almost all of you know, the hooks and the most commonly used hook to manage a local state: useState

useState works great in many scenarios and provides a stable solution without looking into heavier solutions like redux, mobx etc.

Let's take a small look into the basic example of the useState hook:

const { useState } from 'react';

const MyComponent = () => {
  const [count, setCount] = useState(0);
  return (
    <article>
      <h1>Count: <code>{count}</code></h1>
      <button onClick={() => setCount(i => i++)}>Increase count</button>
    </article>
  )
}

Looks very straightforward, very innocent.

And most of the leaf components would look more or less like this, even without the state.

I would use props most of the time as compared to the state. If you have to use the state, that component must not contain much of the JSX, only the barebones passing the state to other Components as props (of course, there are exceptions).

But that's an argument for another time.

For this post, we will imagine a scenario where we don't want to introduce the large-scale state management library for one use case, but our state is getting complicated.

Consider the following wireframe for our application:

Considering the above wireframes, if we were to make the controller component, it would look something like this:

const MyApp = () => {
  const [shoudlOpenNewDataForm, toggleNewDataForm] = useState(false);
  const [confirmSave, toggleSaveConirmationModal] = useState(false);
  const [confirmReset, toggleResetModal] = useState(false);

  // ...
}

Now assume that we need to add one more interaction where we want to allow data editing. This would need us to open the same Form but with some data as the New Data form.

And upon completion of the data adjustment, we want to confirm if the user wants to save the new state.

Additionally, we want to allow the deletion of the data from the Data Editing form.

This would need three additional states to handle this new addition of UI states:

const MyApp = () => {
  const [shoudlOpenNewDataForm, toggleNewDataForm] = useState(false);
  const [confirmSave, toggleSaveConirmationModal] = useState(false);
  const [confirmReset, toggleResetModal] = useState(false);

  const [dataBeingEdited, setData] = useState({});
  const [confirmDelete, toggleDeleteConfirmationModal] = useState(false);

  // ... 
}

Still simple enough?

Let's assume a state of application where we want to allow users to add/update child-level data like access control, permissions, sharing etc., while creating/editing the new data.

This would need a few more additional useState and useRefs

I can keep adding a few more use cases to complicate the state.

And one thing will happen; the controller logic will keep getting bigger and more prone to bugs.

Let's not make the situation insane and look at one of the ways we can keep the problem manageable.

Let's useReducer

`useReducer`

useReducer hook is part of the core library, allowing us to work with the state by dispatching the actions.

This hook works in almost similar ways to useState

Let's take a look at a small example:

import { useReducer } from 'react';

const reducer = (state, action) => {
  switch (action.type) {
    case "open-modal":
      return { modal: action.payload.modal };
    case "close-modal":
      return { modal: null };
    default:
      return state;
  }
};

const Modal = ({ close, name }) => (
  <div>
    <h3>{name} Modal</h3>
    <button onClick={close}>Close</button>
  </div>
);

export const MyApp = () => {
  const [state, dispatch] = useReducer(reducer, { modal: null });
  const openModal = (modal) =>
    dispatch({
      type: "open-modal",
      payload: { modal },
    });
  const closeModal = () => dispatch({ type: "close-modal" });
  return (
    <>
      {state.modal === "info" && <Modal close={closeModal} name="Info" />}
      {state.modal === "confirmation" && (
        <Modal close={closeModal} name="Confirmation" />
      )}

      <button onClick={() => openModal("info")}>Open Info Modal</button>
      <button onClick={() => openModal("confirmation")}>
        Open Confirmation Modal
      </button>
    </>
  );
};

In the above example, we created a Modal to show some content based on the passed parameters.

The above example scenario can be achieved in many ways, but the goal is to exemplify the useReducer hook.

Here are a few critical elements of useReducer:

Parameters

Reducer Function

This function is responsible for changing the state based on the type of action. This function is passed to the useReducer hook as the first argument. This function should be pure, i.e. it should not cause any side effects so that it can be tested independently.

const [state, dispatch] = useReducer(reducer, { modal: null });

Initial State

This is supplied as the initial value to the reducer when executed for the first time. It is also the first render value of the state returned by useReducer

const [state, dispatch] = useReducer(reducer, { modal: null });

Returned Values

The useReducer hook returns an array:

const [state, dispatch] = useReducer(reducer, { modal: null });

Derived `state`

This state must be used in the JSX to determine the next rendered component tree. This is generated by running the reducer function on the previous derived state.

const [state, dispatch] = useReducer(reducer, { modal: null });

Dispatch Function

This is the second element of the returned array from useReducer. This function is used to issue the actions to the reducer function.

const [state, dispatch] = useReducer(reducer, { modal: null });

And here, we can see the above example in action:

Benefits of useReducer

Testability

Along with testing the UI, the reducer function should be pure in ideal scenarios. And this enables the testability of this reducer function.

Modularity

As your function to modify state lives in a separate function instead of the controller Component, you can now move it to a separate file and break it down more to achieve more Modular state derivation.

In the previous case, you must create a custom hook to encapsulate all the useState hooks.

Readability

As Modularity and Testability significantly improve the Code readability, your old component is shorter and has less mental overhead.

Now, let's refactor our initial useState example. As we have yet to define the fully useState model, our useReducer solution will look a lot bigger now.

But for a comparable solution which is scalable and manageable, it would be more significant than useReducer

const removeModal = (modals, modal) => modals.filter((item) => item !== modal);

export const reducer = (state, action) => {
  switch (action.type) {
    case "init-add":
      return {
        ...state,
        currentlyEditing: {},
        modals: [...state.modals, "add-item"]
      };
    case "edit-item":
      return {
        ...state,
        currentlyEditing: action.payload.item,
        modals: [...state.modals, "add-item"]
      };
    case "init-delete":
      return {
        ...state,
        modals: [...state.modals, "confirm-delete"],
        currentlyEditing: action.payload.item
      };
    case "delete-item":
      return {
        ...state,
        modals: removeModal(state.modals, "confirm-delete"),
        currentlyEditing: {},
        data: state.data.filter((item) => item.id !== state.currentlyEditing.id)
      };
    case "init-reset":
      return {
        ...state,
        modals: [...state.modals, "confirm-reset"]
      };
    case "reset-editing-item":
      return {
        ...state,
        modals: removeModal(state.modals, "confirm-reset"),
        currentlyEditing: {
          ...(state.data.find(({ id }) => state.currentlyEditing.id) ||
            initialState.currentlyEditing)
        }
      };
    case "show-modal":
      return { ...state, modals: [...state.modals, action.payload.name] };
    case "hide-modal":
      return {
        ...state,
        modals: removeModal(state.modals, action.payload.name)
      };
    case "update-currently-editing":
      return {
        ...state,
        currentlyEditing: { ...state.currentlyEditing, ...action.payload }
      };
    case "save-currently-editing":
      const { currentlyEditing } = state;
      const probableNewId = new Date().getTime();
      const data = state.data
        .concat(
          currentlyEditing.id
            ? []
            : [{ ...currentlyEditing, id: probableNewId }]
        )
        .map((item) =>
          item.id === currentlyEditing.id ? { ...currentlyEditing } : item
        );
      return {
        ...state,
        data,
        currentlyEditing: {},
        modals: removeModal(state.modals, "add-item")
      };
    default:
      return state;
  }
};

export const initialState = {
  data: [
    { name: "A", id: 1 },
    { name: "B", id: 2 }
  ],
  currentlyEditing: {},
  modals: []
};

With the above example, all application changes can not be reflected in changes to Data; hence, the code is highly testable and reliable.

If we want to check whether the Modal to add a new item is open or not, we need to check the presence of add-item element in the Modals array, let's look at the example.

describe('data table reducer', () => {
  it('should add add-item modal when add is triggered', () => {
    expect(
      reducer({}, { type: 'init-add' }).modals
    ).toEqual(['add-item']);
  });

  it('should add add-item modal when edit is triggered', () => {
    const action = {
      type: 'edit-item',
      payload: { item: {a: 1, b: 2} }
    };
    const updatedState = reducer({}, action);
    expect(updatedState.modals).toEqual(['add-item']);
    expect(
      updatedState.currentlyEditing
    ).toEqual(action.payload.item);
  });
});

Conclusion

Have you used useReducer?

What are some tips you would consider keeping in mind while using useState and useReducer?

Let me know through comments. or on Twitter at @heypankaj_ and/or @time2hack

If you find this article helpful, please share it with others.

Subscribe to the blog to receive new posts right in your inbox.

Can I use hover on Touch Devices?

Pankaj Patel — Wed, 09 Mar 2022 08:28:14 +0000

Current web development is revolving around responsiveness when it comes to supporting multiple form factors.

Though the hardware tech is also pacing itself forward we can see huge variety of handheld devices as they are portable and powerful.

Current Challenge

But this brings a huge dilemma in front of Frontend developers (a.k.a web developers).

How did we NOT handle hover in mobile/handheld/touch-enabled devices?

With Responsive Media Queries and adding touch event handlers. On smaller devices don't add hover CSS and add touch handlers to see additional content.

And it worked great for the following reasons:

Small form factor meant touch
Bigger screens always come with mouse support

But nowadays, we have:

Huge tablets in both categories of portable & large screenScreens are like a desktop but you can use these like tablets, which means you won't have access to Mouse or precise control of the pointer
Hover on tablet-y desktops (or desktop-y tablets 🤷‍♂️)

The good old mouse interactions are no longer available on such devices. Interactions like:

hover
right-click

Solution

CSS3 have now covered this corner now with pointer media queries. It allows you to write CSS for the following values:

pointer: coarse
pointer: fine
pointer: none

Let's take a look at an example use of the above media queries:

<button
  data-title="Get the best offers!"
  data-help="Call 1800-00-00-123456!"
>
  Subscribe
</button>

button {
  color: #333;
  font-size: 1.3rem;
  padding: 2rem;
  background-color: #eee;
  border: 1px solid #ddd;
  position: relative;
  transition: all ease 200ms;
}

@media (pointer: fine) {
  button:hover {
    color: #fff;
    border-color: #000;
    background-color: #333;
  }
  button:hover:after {
    top: 90%;
    background: #aaa;
    border-radius: 0.25rem;
    content: attr(data-title);
    position: absolute;
    font-size: 0.7rem;
    padding: 0.5rem 0.8rem;
    width: max(100%, 200px);
    max-width: max-content;
  }
}

@media (pointer: coarse) {
  button:after {
    content: attr(data-title);
    display: block;
    font-size: 0.75rem;
  }
  button:hover {
    color: #ddd;
    border-color: #aaa;
    background-color: #999;
  }
}

See the Pen
Untitled by Pankaj Patel (@pankajpatel)
on CodePen.

And you can also detect if no pointing is present with the device; like in following example:

@media (pointer: none) {
  button:before, button:after {
    display: block;
    font-size: 0.75rem;
  }
  button:after {
    content: attr(data-title);
  }
  button:before {
    content: attr(data-help);
  }
}

Hover in JS?

In our Desktop WebApps, we tend to add much interaction on Hover, But if we want the same apps to be usable on Touch devices, our JS-based interactions seem to have rendered useless.

We usually leave the hover events in place and attach extra handlers like touch-&-hold or similar.

But I think that it is not the best way, we should add hover interactions only when we know that hover is possible and the same for touch events.

For this, we have an all-around solution that allows us to run a CSS media query and see if the operation matched or not.

Yes we are talking about window.matchMedia

You can use matchMedia function to see if the window is under any responsive breakpoint or not:

console.log(
  window.matchMedia('(max-width: 768px)')
);
// { matches: false, media: "(max-width: 768px)", ... }

Now we can use a similar matchMedia query to determine the pointer support. For example:

document.addEventListener('DOMContentLoaded', () => {
  const pointerFineSupported = window.matchMedia('(pointer: fine)').matches

  if (pointerFineSupported) {
    document.querySelector('a')?.addEventListener('hover', (e) => {
      // load the linked content optimistically before click
    })
    document.querySelector('image')?.addEventListener('mouseenter', (e) => {
      // show the related caption
    })
    document.querySelector('image')?.addEventListener('mouseleave', (e) => {
      // hide the related caption
    })
  }
});

Similarly, we can attach Touch Events like touchstart and touchend when the pointer: coarse is available

document.addEventListener('DOMContentLoaded', () => {
  const touchSupported = window.matchMedia('(pointer: coarse)').matches

  if (touchSupported) {
    document.querySelector('image')?.addEventListener('touchstart', (e) => {
      // show the related caption
    })
    document.querySelector('image')?.addEventListener('touchend', (e) => {
      // hide the related caption
    })
  }
});

Let's put the above JS snippet to use and make something UX improvements where we have used the pointer media queries to optimize the page navigation.

The prime difference between the two is:

const pointerFineSupported = window.matchMedia('(pointer: fine)').matches;

if (pointerFineSupported) {
  document.querySelectorAll('[data-prefetch]').forEach(el => {
    el.addEventListener('mouseenter', (e) => {
      const routeName = el.getAttribute('href').replace('#', '');
      !routes[routeName].content && fetchTemplateForRoute(routes[routeName]);
    })
  })
}

Repo: https://github.com/time2hack/pointer-events
Demo without optimization: https://time2hack.github.io/pointer-events/
Demo with optimization: https://time2hack.github.io/pointer-events/index2.html

In my portfolio website; I have also used the pointer media queries in CSS to show some information that is visible on hover if you are using a desktop with a mouse to visit it.

Here is the rough outline of the Styled Component for the Card handing pointer media query:

import styled from "styled-components";

export const ImageContainer = styled.div`
  ...
  & img { ... }
`;

export const Description = styled.div` ... `;

export const Article = styled.article`
  ...

  ${ImageContainer} { ... }

  &:hover {
    & ${Description} { ... }
  }

  @media (pointer: coarse) {
    ...

    ${Description} { ... }
  }
`;

You can see the full file here: https://github.com/pankajpatel/pankajpatel.github.io/blob/master/components%2Fstyled%2FArticle.ts

Conclusion

Pointer media queries can help you tailor the UX for devices that have capabilities, like

Prefetch content on hover for mouse
Slide interaction for list items on touch devices
etc.

What are you going to optimize?

Let me know through comments 💬 or on Twitter at @heypankaj_ and/or @time2hack

If you find this article helpful, please share it with others 🗣

Subscribe to the blog to receive new posts right to your inbox.

Ways to convert String to Number in JS

Pankaj Patel — Mon, 14 Jun 2021 06:12:32 +0000

Converting from one type to another (or simply called typecasting) is needed very frequently in any programming language. So is in JavaScript.

Today we are going to take a look at some of the ways to Typecast Strings to Number.

parseInt

As the name suggests, parseInt the function parses the argument as Integer. Though parseInt is made to parse to String to different kinds of Integers like Decimal, Binary, Octal etc

With the above definition, parseInt accepts two parameters:

string: The value that needs to be converted to an integer
integer: The radix base number between 0 and 32

Examples:

parseInt('123', 10) // 123
parseInt('111', 2) // 7
parseInt('111', 8) // 73
parseInt('111', 9) // 91
parseInt('111', 10) // 111
parseInt('111', 16) // 273
parseInt('111', 32) // 1057
parseInt('111', 36) // 1333
parseInt('111', 37) // NaN

Few things to remember here when using parseInt:

radix base must be number; if not, it will be coerced to Number
the base must be provided

parseFloat

Similar to parseInt, parseFloat the function will parse the string as a Floating number.

As there is no Floating representation in other number systems except Decimal; there is only Decimal parsing of String.

Example usage of parseFloat can be:

const stringInt = '10';
const parsedStrInt = parseFloat(stringInt);

console.log(parsedStrInt, typeof parsedStrInt);
// 10 "number"

const stringFloat = '10.66';
const parsedStrFlt = parseFloat(stringFloat);

console.log(parsedStrFlt, typeof parsedStrFlt);
// 10.66 "number"

Number

Another way to convert/typecast Strings to Integer/Float is Number function. It works in the same way as of parseFlot

Applying the same example of parseFloat on Number will give us the same results

const stringInt = '10';
const parsedStrInt = Number(stringInt);

console.log(parsedStrInt, typeof parsedStrInt);
// 10 "number"

const stringFloat = '10.66';
const parsedStrFlt = Number(stringFloat);

console.log(parsedStrFlt, typeof parsedStrFlt);
// 10.66 "number"

Benefits of using Number over parseFloat can be verbosity and readability of the JavaScript program.

Unary Operators

Unary operators are not really the type-casters but because of the way JS works, we can use the Unary operators to convert String to Number without hassle.

Let's take a look at an example first:

const oldNumber = '5'
const newNumber = +oldNumber

console.log(oldNumber, typeof oldNumber)
// 5 "string"

console.log(newNumber, typeof newNumber)
// 5 "number"

Here on the like 2 if we see that we used unary operator + to convert a String value to a Number.

For the purpose of converting the String to Number, will use only two unary operators:

Unary Plus

Unary Plus will convert the String to Number without making any effort on changing the direction on the number axis

const oldNumber = '5'
const newNumber = +oldNumber

console.log(oldNumber, typeof oldNumber)
// 5 "string"

console.log(newNumber, typeof newNumber)
// 5 "number"

const oldNegativeNumber = '-5'
const newNegativeNumber = +oldNegativeNumber

console.log(oldNegativeNumber, typeof oldNegativeNumber)
// -5 "string"

console.log(newNegativeNumber, typeof newNegativeNumber)
// -5 "number"

Unary Minus

Unary Minus will try to convert the String and Number and reverse the Sign on Number (reverse the direction on the number axis)

const oldNumber = '5'
const newNumber = -oldNumber

console.log(oldNumber, typeof oldNumber)
// 5 "string"

console.log(newNumber, typeof newNumber)
// -5 "number"

const oldNegativeNumber = '-5'
const newNegativeNumber = -oldNegativeNumber

console.log(oldNegativeNumber, typeof oldNegativeNumber)
// -5 "string"

console.log(newNegativeNumber, typeof newNegativeNumber)
// 5 "number"

Binary Operators

Another way to convert string to number is by using Binary operators. Operators like -, * and /.

For example:

const num = '1234';

const minusNum = num - 0;
console.log(minusNum, typeof minusNum);
// 1234 "number"

const multiplyNum = num * 1;
console.log(multiplyNum, typeof multiplyNum);
// 1234 "number"

const divideNum = num / 1;
console.log(divideNum, typeof divideNum);
// 1234 "number"

But how? here are the few things going on:

JS evaluates an expression from left to right
JS will try to match the type of operands on both sides of the operator
End result is dependent on the type of operands needed by the operator
One of the operands will be a number that will not result in any changes to the final value like multiplication & division by 1 or addition or removal of 0

Note: We can use + but it has concatenation behaviour which will try to convert Number to String which we don't want here.

With Binary Operators, you can also change the Sign of Number on go. Let's do so with the above code example:

const num = '1234';

const minusNum = 0 - num;
console.log(minusNum, typeof minusNum);
// -1234 "number"

const multiplyNum = num * -1;
console.log(multiplyNum, typeof multiplyNum);
// -1234 "number"

const divideNum = num / -1;
console.log(divideNum, typeof divideNum);
// -1234 "number"

Let me know through comments 💬 or on Twitter at @patel_pankaj_ and/or @time2hack

If you find this article helpful, please share it with others 🗣

Subscribe to the blog to receive new posts right to your inbox.

Originally published at https://time2hack.com on June 13, 2021.

3 Must haves for Merge Requests for swift Code Review

Pankaj Patel — Fri, 09 Apr 2021 14:50:03 +0000

One huge part of Code Collaboration is Merge Requests (MR).

Here you can tell other members of the Repository about your Code Solution.

Let's make sure that the Reviews on your Merge Requests is as swift as possible.

Not only for you, but for the reviewers

1. Title

The title is very important for a good MR. A good title should explain what the MR is about.

Think of it as the SEO Title of your WebPage.

If it is misleading, the reviewers would have to struggle hard to get the Core Idea or reason for the Merge Request.

For example:

Bad: Refactoring Components

Good: ABC-123: Refactor Login Flow for Better Error Handling

It tells me that:

Ticket is present for this change
What parts of UI should expect some change
Reason for Change

2. Brief Description

Of course, the title can not have everything.

That's why there is the description.

It should briefly touch base on Major changes done to achieve the title.

For the above title of MR, the following could be a good description: ""

- Removed unnecessary Props
- Adopted composition of Component and reduced Prop Drilling
- UI Error reporting is unified for a form via the `useErrors` hook
- Inputs are now logic-less allowing better testing

Now with the above description, I would be expecting the File changes and pay more attention to the Code in certain areas.

3. Related Ticket/Issue

A change should be introduced to Code with some Ticket.

This ticket can be Bug, Feature/Story, Task etc.

Presence of ticket allows+maintains the Documentation and Reasoning of Change outside the Repository.

With things outside the code, it allows collaboration from non-code participants.

In some of the cases, Ticket and MR are in the same system.

For instance, Issues from GH are tickets for PR

Conclusion

I think that the above points allow the reviewer to prepare for what they are going to review.

What would you need as a Reviewer as a must-have?

Let me know through comments 💬 or on Twitter at @patel_pankaj_ and/or @time2hack
If you find this article helpful, please share it with others 🗣
Subscribe to the blog to receive new posts right to your inbox.

When NOT to choose Next.js

Pankaj Patel — Mon, 22 Mar 2021 13:46:51 +0000

Next.js has been the talk of the town since its release.

And, all I could hear was how awesome is next.js.

I decided to give it a try. I sat down throughout the weekend & followed the official documentation/getting-started guide. I managed to create a small Markdown-files-powered Blog.

😎

As I have a blog, I thought of generating my blog’s Next.js website with the previous code of Markdown files’ powered Blog.

https://beta.deckdeckgo.io/pankajpatel/nextjs/

And I finished it. I was super happy. Finally; after a long time, I finished a side project (sort of) 🎉.

With this, I started to like next.js.

🥰

🏎💨 Fast forward to 2 weeks later.

I enjoyed using Next.js, so I suggested using Next.js for a new app (kind of new) for the company.

The plan was to break down the current frontend app and migrate a small part to a new App repository.

So I sat down to using Next.js for the new (splitter up & migrated) code

After two days of work, I somehow migrated some code and managed to make it work with Next.js. But now I am stuck with more work somehow.

On the third day, I decided to drop the Next.js idea and start the new app with CRA (Create React App)

Here are my conclusions on When not to choose Next.js

Existing Codebase

If you are not ready for a major refactor and testing effort around it, I would suggest not to jump on to Next.js Bandwagon.

Next.js is and powerful and cool.

For a completely new project, I would recommend using Next.js

But you should analyse the available time, refactoring efforts and testing needs of your existing codebase.

Runs on Node.js server

So far, all the conventional React apps had been on a single HTML file many JS files chunked-&-joined together on the need (URL, device, etc) basis.

Now, next.js provides fast response time, effective code-splitting, Server Side Rendering and many other things. All these awesome features with the help of a Node.js server responding to all the requests.

If your previous app was a conventional single HTML file, you should rethink it.

One can say, you can Export/Generate the site & use it in an old conventional way.

But then you are using Next.js for not what it is capable of doing. And hence, you don’t even need it in the First Place.

You wanted a needle to fix up a button on your shirt and here you are, handling the task with a sword.

API Routes

Yes, Next.js provides API routes. You can pretty much create your server there which can act as your Backend and do a complex thing. All the BE and FE code in one place.

But, Next.js’s API capabilities should be used to create an API Proxy or Middleware and do the small scale operations.

Heavy lifting or Business Logic should be created in APIs which can be fine-tuned and secured.

Everything at one place will either bring real API to the standard of FE’s vulnerability or make FE move slowly.

Refactoring Effort

In a conventional React App, where components are rendered on Routes from react-router (or similar), File-based routing will shake things a lot.

You might have to rethink your component arrangement and how they are being added to the Page-level components.

You would need to rethink the Store of your application.

This invites a lot of effort in refactoring and hence a lot of testing to make sure again that the app is working fine.

CDN

As the assets are not static, you can not use CDNs anymore

Though if you choose to export your website, and you are using a hybrid of SSR and SSG, it is possible to use CDNs.

In the end, we went with Create React App as it solved all the initial configuration needs and gets out of the way. It fits our current application arrangements.

Though we needed some customisations. We managed to make adjustments with the help of craco.

Conclusion

With next.js you can create blazing fast web apps.

Though be careful while choosing to use Next.js for your next application.

Let me know through comments 💬 or on Twitter at @patel_pankaj_ and/or @time2hack

If you find this article helpful, please share it with others 🗣

Subscribe to the blog to receive new posts right to your inbox.

Originally published at https://time2hack.com on March 22, 2021.

TIL: cache-control is as inconsistent as it can get in different Browsers

Pankaj Patel — Fri, 05 Feb 2021 16:49:57 +0000

Today a colleague started asking questions on cache-control and how to achieve consistent behaviour so that he can control it from Server Side

Then another colleague pointed out a StackOverflow thread where the answer makes sense but raises a question on why do these differences exist?

Feb 12 '13

129

I got it. Google Chrome ignores the Cache-Control or Expires header if you make a request immediately after another request to the same URI in the same tab (by clicking the refresh button, pressing the F5 key or pressing Command + R). It probably has an algorithm to guess…

Open Full Answer

I think I still don't understand it completely after this revelation.

I suggested that we can use Service Workers to intercept all requests and implement better caching strategy there.

In response, another colleague pointed out that SWs are not worth the work and the support is inconsistent.

which lead me to here: https://caniuse.com/serviceworkers

Which again raises this question what is best approach to control caches from server?

Fixing WebpackChunkName for Dynamic Imports

Pankaj Patel — Wed, 27 Jan 2021 13:22:22 +0000

Lazy Loading is a hot topic for optimization of the web application.

I was trying to optimize the React App and as we already have splitChunks in our webpack configuration, it was for granted to pay more attention to code splitting.

I thought of analyzing our bundle with Webpack Bundle Analyzer and see how splitChunks has a done the splitting.

For some reason, I could not identify the Chunks by name as they were pretty random as 1234.asdfd23534kjh346mn63m46.chunk.js

So to resolve this, I updated the chunkName in output of webpack config to [name].[contenthash].chunk.js

But still no luck! Bundle analyzer was still showing the chunk names similar to 1234.asdfd23534kjh346mn63m46.chunk.js

🚀 Web Search to the rescue, I found Magic Comments in Webpack

And to name my chunks I added magic comments similar to following on all dynamic imports in the codebase

export default Loadable({
  loader: () => import(
    /* webpackChunkName: Dasahboard */
    './containers/Dashboard'
  ),
  loadaing: () => <Spinner />
})

Still no luck 😕

Getting on to more Web Search 💪

Then I came across a comment in one of the web pack’s repo:

Turn the comment on in your babel configuration for the project

After struggling for a few minutes and a few trial and errors, I realised that I don’t need to configure comments in babel configuration. Its because I am using the presets in Babel; comments are on by default.

Still no luck 😫. Magic Comments are not reaching Webpack.

If Magic Comments (or Any Comment) are not reaching webpack, then they are lost in transpiling process. Which means I need to dig deeper in Babel Configuration.

Then I started going through all of the plugins in the Babel configuration.

{
  ...
    "plugins": [
    "dynamic-import-webpack",
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-syntax-object-rest-spread",
    [
      "@babel/plugin-transform-runtime",
      {
        "corejs": 3
      }
    ]
  ],
  ...
}

From this list of plugins, the only plugin that might be the culprit is dynamic-import-webpack

A small plugin to make dynamic imports i.e. import() work. Which you can see here: GitHub - airbnb/babel-plugin-dynamic-import-webpack: Babel plugin to transpile import() to require.ensure, for Webpack

What’s special here? The First line of the Readme of the repo:

Babel plugin to transpile import() to require.ensure, for Webpack.

And this is what is causing all the trouble. As imports are transformed to require.ensure there are no more magic comments.

So as a solution, removed this plugin dynamic-import-webpack from Babel and Magic Comments take effect in Webpack.

Now the Chunks have names similar to List. asdfd23534kjh346mn63m46.chunk.js

Conclusion

Configuring webpack can be tricky when there are so many things going on. If you want the Chunks to be named properly; I would suggest going through the following checklist:

chunkName in output is configured properly
Magic comment /* webpackChunkName: MyChunk */ is used to name the chunk
Babel is configured to NOT remove the comments
And remove plugin dynamic-import-webpack

Bonus tip

Use webpackPrefetch: true magic comment with webpackChunkName . And consider adding service workers with good caching strategy.

This will cache the Files on Browser and avoid problems related to Chunks not found (Chunk loading failed) with multiple deploys.

As you are using [contenthash] in the output file names, only the changed modules will be cached again by service workers, not all the files.

Let me know through comments 💬 or on Twitter at @patel_pankaj_ and/or @time2hack

If you find this article helpful, please share it with others 🗣

Subscribe to the blog to receive new posts right to your inbox.

Credits

Photo by Ferenc Almasi on Unsplash

Originally published at https://time2hack.com on Jan 21, 2021.

Gatsby or Next.js?

Pankaj Patel — Sun, 17 Jan 2021 13:47:18 +0000

Hey all,

Just wanted to know about what community thinks when choosing between Gatsby and NextJS?

Do you use any other SSG other than Gatsby or Next.js like

React Static
Eleventy
Hugo
etc. which one?

🚦 Submitting a Form to different Actions in HTML5

Pankaj Patel — Wed, 13 Jan 2021 14:57:16 +0000

For so long, I had believed that one Form can only be submitted to one Action URL without any JS.

I couldn’t be more wrong.

Though, lets take a look at the way of the Past i.e. with JavaScript and AJAX/Fetch

Problem

Consider following HTML Form where we want to add or update addresses to the User Profiles.

<form id='addressForm'>
  ...
  <!-- Form Fields -->
  ...
  <button id='addAddress' class="btn btn-primary">Add Address</button>
  <button id='updateAddress' class="btn btn-success">Update Address</button>
</form>

In the above form, there are submit buttons to Add Address or Update Address Though they will only send POST request to /addAddress .

Which means the Update Address will still lead to adding a new address rather than updating the current one.

To make this work, we will need to use JavaScript.

Now with JavaScript, there are multiple ways to do so. One simple way is to submit form via AJAX request

Let’s see how to submit the above Form to different Action endpoints with AJAX:

document.addEventListener('DOMContentLoaded', () => {
  const form = document.querySelector('#addressForm')
  const addButton = document.querySelector('#addAddress')
  const updateButton = document.querySelector('#updateAddress')

  addButton && addButton.addEventListener('click', (e) => {
    e.preventDefault()

    if (!form.checkValidity()) {
      return
    }

    fetch('/addAddress', { method: 'POST', body: new FormData(form) })
      .then((r => r.json()))
      .then(console.log)
  })

  updateButton && updateButton.addEventListener('click', (e) => {
    e.preventDefault()

    if (!form.checkValidity()) {
      return
    }

    fetch('/updateAddress', { method: 'POST', body: new FormData(form) })
      .then((r => r.json()))
      .then(console.log)
  })
})

Now as we can see that with JavaScript the HTML and deform submitting is very tightly coupled.

This old way of sending Form to multiple endpoints can be checked on https://multi-action-forms.netlify.app/with-ajax.html

Now what is the solution?

Solution

I came across these attributes for the submit buttons, where you can specifically make the form to be submitted on different URL with different HTTP method and encoding type.

Those attributes are fromaction, formmethod and formenctype.

With these attributes, we can go back to adding a normal submit button and default attributes to the form.

Along with that, we will add another submit button with attributes mentioned in the previous line.

Here’s how new HTML Form will look like:

<form action="/addAddress" method="POST">
  ...
  <!-- Form Fields -->
  ...
  <button type="submit" class="btn btn-primary">Add</button>
  <button type="submit" class="btn btn-success" formaction="/updateAddress" formmethod="POST">Update</button>
</form>

Not just on Buttons, but on input of type button also accepts these attributes to allow sending Form Submissions to different endpoints.

Benefits

No need to attach JS for basic functionalities
HTML5 Validation API can be leveraged with its normal flow
Form can work in Pages with JS disabled (with exceptions)

Concerns

Browser Support, the old browsers might not work with this and hence you might need Polyfills/Shims
Modern Front End apps like Single Page Applications, MicroFrontends etc might need some extra tuning with work with this

time2hack / multi-action-forms-example

Demo

Conclusion

As we saw how we can utilize the Browser’s inbuilt APIs to get more things done with less code.

Would you use in you application? Why or Why not?

Let me know through comments 💬 or on Twitter at @patel_pankaj_ and/or @time2hack

If you find this article helpful, please share it with others 🗣

Subscribe to the blog to receive new posts right to your inbox.

Credits

Icon from Iconfinder
Photo by Mitchell Luo on Unsplash

Originally published at https://time2hack.com on Jan 13, 2021.

Building Fast Forms in React with HTML5 & Validations

Pankaj Patel — Tue, 15 Dec 2020 09:43:13 +0000

If you are making a web app, you will need to create Forms most of the time. Forms are notorious for demand in Creativity and Customizability.

One of the ways we can ease the Form handling is by representing Forms in Data and Functions. And with this representation, we can create, read and update the Form elements.

So to start with, let’s see a list of possible Form Elements that can take part in Form or Act on it:

Text
Email
Date
Time
Password
Number
File
Hidden
Tel
Checkbox
Radio
URL
Range
Search
etc. (week, image, month, reset, submit, …)

Now let’s try to create a JS Object representation for one of these inputs, text:

const fields = [
  {
    type: "text", // input type
    name: "fullName", // Form input name
    label: "Full Name", // Label for Input
    placeholder: "John Doe" // Placeholder
  }
]

And Lets create this input type text in React:

// Input.js
import React from "react";

export function Input({ field }) {
  const id = `input-id-${+Date.now()}-${Math.random()}`
  return (
    <div className="form-field">
      <label htmlFor={id}>{field.label}</label>
      <input
        id={id}
        type={field.type}
        name={field.name}
        placeholder={field.placeholder}
      />
    </div>
  )
}

🤔 But what about events? We need values from the Form!

Well, we will use FormData API to collect values from the Form.

🤨 But we still need events to validate the Values!

We will use HTML5’s native form validation to prevent submit.

Though, if we need advanced validation. We can add the post processors to operate and change the values before sending them to the Server

const fields = [
  {
    type: 'text', // input type
    name: 'fullName', // Form input name
    label: 'Full Name', // Label for Input
    placeholder: 'John Doe', // Placeholder
    required: true
  }
]

And with above field definition we can create different Inputs. Though, for different text based inputs, we will have our Input component as the following:

// Input.js
import React, {useRef} from 'react'
import TextInputRenderer from './InputType/Text'

const getRenderer = (type) => {
  switch(type.toLowerCase()) {
    case 'tel':
    case 'url':
    case 'text':
    case 'date':
    case 'time':
    case 'file':
    case 'week':
    case 'month':
    case 'image':
    case 'email':
    case 'color':
    case 'range':
    case 'number':
    case 'search':
    case 'password':
      return TextInputRenderer
    default: return 'div'
  }
}

const Input = ({ field = {} }) => {
  const inputRef = useRef(null)
  const Component = getRenderer(field.type)

  return (
    <div className="form-field">
      <Component
        {...field}
        ref={inputRef}
        onChange={() => console.log(inputRef.current)}
      />
    </div>
  )
}

export default Input

// components/InputType/Text.js
import React, {Fragment} from 'react'

export default React.forwardRef((props, ref) => {
    const id = `input-id-${+Date.now()}-${Math.random()}`
    return (
    <Fragment>
      <label htmlFor={id}>{props.label}</label>
        <input id={id} {...props} ref={ref} />
      </Fragment>
    )
})

In above code, we have extracted the text-based input to components/InputType/Text.js. Input component will only take care of attaching the necessary refs and handlers.

Here, one thing to notice is React’s forwardRef, it takes a ref passed as a prop and forwards it to the child component.

Before moving forward, as we can see that we are using the unique ID generation logic. We can extract this logic to a separate utility function:

// src/utils/get-id.js
export default () => [
  'input',
  +Date.now(),
  Math.random()
].join('-')

In future, we can use a robust UUID with libraries like uuid

Now the inputs Radio, Select and Checkbox render in different Markup.

Checkbox

In general, for singular checkboxes, it renders like text inputs. Though a common use case can be on Checkbox List and this is where we need to change the rendering of the component

import React, {Fragment} from 'react'
import getId from '../../utils/get-id'

export default React.forwardRef((props, ref) => {
  const id = getId()
  return (
    <Fragment>
      <label htmlFor={id}>{props.label}</label>
      {props.options ? (
        <span className="flex-col">
          {props.options.map(item => {
            const id = getId()
            return (
              <span key={id}>
                <input id={id} {...props} value={item.value} />
                <label htmlFor={id}>{item.label}</label>
              </span>
            )
          })}
        </span>
      ) : <input id={id} {...props} ref={ref} />}
    </Fragment>
  )
})

Radio

For Radio Group, all inputs have the same name. And, Field Definition needs to accept the list of options to generate a Radio button list.

import React, {Fragment} from 'react'
import getId from '../../utils/get-id'

export default React.forwardRef(({options, label, ...props}, ref) => (
  <Fragment>
    <label>{label}</label>
    <span className="flex-col">
      {options.map(item => {
        const id = getId()
        return (
          <span key={id}>
            <input id={id} {...props} value={item.value} />
            <label htmlFor={id}>{item.label}</label>
          </span>
        )
      })}
    </span>
  </Fragment>
))

Select

Selects have options and differ in basic rendering. Hence we need to create a different component for Selects.

import React, {Fragment} from 'react'
import getId from '../../utils/get-id'

export default React.forwardRef(({options, ...props}, ref) => {
  const id = getId()
  return (
    <Fragment>
      <label htmlFor={id}>{props.label}</label>
      <select ref={ref} {...props}>
        {options.map(item => (
          <option key={item.value} value={item.value} selected={item.selected}>
            {item.label}
          </option>
        ))}
      </select>
    </Fragment>
  )
})

Now that our for is set up, we need to handle the validations in our form.

Validations for example:

required field
min and max
maxLength and minLength
pattern
email
url
etc.

For this, we need to go back to the Field Definitions. We need to add the needed attributes respective to the type of input & desired validations. Considering this, the following could be a combination:

export default [
  {
    type: 'text', // input type
    name: 'fullName', // Form input name
    label: 'Full Name', // Label for Input
    placeholder: 'John Doe', // Placeholder
    pattern: '[A-Za-z\\s]{1,}',
    required: true
  },
  {
    type: 'date', // input type
    name: 'dob', // Form input name
    label: 'Date of Birth', // Label for Input
    required: true
  },
  {
    type: 'number', // input type
    name: 'workCapacity', // Form input name
    label: 'Weekly Work Capacity', // Label for Input
    required: true,
    min: 10,
    max: 8*7, // 8 hrs per day for 7 days of week
    step: 4 // half day steps
  },
  {
    type: 'file', // input type
    name: 'profilePicture', // Form input name
    label: 'Profile Picture', // Label for Input
    required: true
  },
  {
    type: 'radio',
    name: 'gender',
    label: 'Gender',
    required: true,
    options: [
      {
        label: 'Male',
        value: 'M'
      }, {
        label: 'Female',
        value: 'F'
      }, {
        label: 'Other',
        value: 'O'
      }, {
        label: 'I\'d rather not specify',
        value: '-'
      },
    ]
  },
  {
    type: 'checkbox',
    name: 'foodChoices',
    label: 'Food Choices',
    options: [
      {
        label: 'Vegan',
        value: 'V+'
      }, {
        label: 'Vegetarian',
        value: 'V'
      }, {
        label: 'Non Vegetarian',
        value: 'N'
      }, {
        label: 'I\'d rather not specify',
        value: '-'
      },
    ]
  },
  {
    type: 'select',
    name: 'primaryLanguage',
    label: 'Primary Language',
    required: true,
    options: [
      {
        label: 'English (US)',
        value: 'en_US'
      }, {
        label: 'English (UK)',
        value: 'en_UK'
      }, {
        label: 'Deutsch',
        value: 'de_DE'
      }, {
        label: 'French',
        value: 'fr_FR'
      }
    ]
  },
  {
    type: 'email',
    name: 'email',
    label: 'Your Email',
    required: true
  },
  {
    type: 'tel',
    name: 'phoneNumber',
    label: 'Your Phone Number',
    required: false,
    pattern: '[+0-9]{8,12}'
  },
  {
    type: 'url',
    name: 'homepage',
    label: 'Your Website',
    required: false
  },
  {
    type: 'password',
    name: 'password',
    label: 'Your Password',
    required: true
  },
  {
    type: 'password',
    name: 'confirmPassword',
    label: 'Confirm Password',
    required: true
  },
  {
    type: 'checkbox',
    name: 'terms',
    label: '',
    required: true,
    options: [{
      value: 'yes',
      label: 'Terms and Conditions'
    }]
  }
]

Which gives us the field in the HTML form as:

And with the validations of HTML5, it will trigger the errors until the Form is completely filled.

Though there are some validations which are still required. HTML5 validation with attributes can’t acomplish this.

For this, we will need custom validation via the HTML5’s Validation API

HTML5’s Validation API offers very elaborate properties and methods to tap into the HTML5’s validation features.

First to start with is the ValidationState interface. ValidationState Interface provides the boolean state with respect to the validation Attributes on Input elements. For example:

valueMissing is boolean answer of required
tooLong for maxLength
tooShort for minLength
rangeOverflow for max
rangeUnderflow for min
patternMismatch for pattern
stepMismatch for the value to match or be divisible by step
typeMismatch in case of value is not like the input type; only useful in case of url and email
valid for Input value to be valid and passes all the validation checks
customError if any custom error has been set.

Another part is via very specific methods setCustomValidity and reportValidity. We will use these methods to report our custom validations.

For any input field,

setCustomValidity will set the custom error on the input element
reportValidity will make the validation error visible on the input element
customError is set to true if error is set via setCustomValidity

For above to take effect, let’s introduce some custom validations. We use one of the fields above, foodChoices:

  ...
  {
    type: 'checkbox',
    name: 'foodChoices',
    label: 'Food Choices',
    options: [
      ...
    ],
+    validations: [
+      (value, name, allFormValues, form) => ([
+        Boolean(allFormValues[name]),
+        `Please select atleast one of ${name}`
+      ]),
+      (value, name, allFormValues, form) => ([
+        ['V+', 'V', 'N', '-'].includes(value),
+        `Please select only from the provided choices for ${name}`
+      ])
+    ]
    },
  ...

We introduce a validations key which will accept an array of validators.

These validators will return the validity state and Error to show if not valid.

The arguments to these validators will follow the sequence of

value of the field
Name of the field
All the values of the Form to compare and use
Form itself to operate on a higher level, not needed most of the time

And with the above validations, we will need some Functions in Form component to handle the Form submit.

The Input component will also need the change as when we report the errors. Also, we need to run the checks immediately and clear the error once the field is valid.

Lets start by taking a look at the change in Checkbox renderer:

// src/components/InputType/Checkbox.js
import React, {Fragment, useRef, useEffect} from 'react'
import getId from '../../utils/get-id'

export default React.forwardRef(({registerField, ...props}, ref) => {
  const refs = useRef([])
  refs.current = (props.options || []).map(item => useRef(null))
  useEffect(() => {
    registerField(props.name, props.options ? refs : ref)
  }, [registerField, props.name, props.options])
  const id = getId()
  return (
    <Fragment>
      <label htmlFor={id}>{props.label}</label>
      {props.options ? (
        <span className="flex-col">
          {props.options.map((item, index) => {
            const id = getId()
            return (
              <span key={id}>
                <input id={id} {...props} value={item.value} ref={refs.current[index]} />
                <label htmlFor={id}>{item.label}</label>
              </span>
            )
          })}
        </span>
      ) : <input id={id} {...props} ref={ref} />}
    </Fragment>
  )
})

And the Input component which renders the Checkbox will change as follows:

// src/components/Input.js
// ...
// code above here is same as before for renderers
const Input = ({
  field = {},
  onChange = () => {},
  registerField = () => {},
}) => {
  const inputRef = useRef(null)
  const Component = getRenderer(field.type)
  return (
    <div className="form-field">
      <Component
        {...field}
        ref={inputRef}
        registerField={registerField}
        onChange={(...args) => onChange(field.name, ...args)}
      />
    </div>
  )
}

And now the Form component which will utilise the above changes to do manual validation:

export default function Form() {
  const form = useRef(null)
  const inputWithError = useRef(null)
  const fieldRefs = useRef({})

  const registerField = (key, ref) => {
    fieldRefs.current = {...fieldRefs.current, [key]: ref}
  }

  const getField = (key) => {
    return (
      Array.isArray(fieldRefs.current[key].current)
        ? fieldRefs.current[key].current[0]
        : fieldRefs.current[key]
    ).current
  }

  const resetError = (errorFieldKey) => {
    if (errorFieldKey) {
      const field = getField(errorFieldKey)
      if (!field) {
        return
      }
      field.setCustomValidity('');
      field.reportValidity();
    }
  }

  const handleChange = (key, ...args) => {
    resetError(inputWithError.current)
  }

  const customValidations = FIELDS.reduce(
    (acc, field) => field?.validations
      ? {...acc, [field.name]: field.validations}
      : acc
    , {}
  )

  const onSubmit = (e) => {
    e.preventDefault()
    if (inputWithError.current) {
      resetError(inputWithError.current)
    }

    if (!form.current.checkValidity()) {
      return false;
    }

    const formData = serialize(new FormData(form.current))

    let error = null
    // Check for custom validations
    const isValid = Object.keys(customValidations).reduce((acc, key) => {
      const validations = customValidations[key]
      const validity = validations.reduce((prevResult, validatorFn) => {
        // short circuit the validations if previous one has failed
        if (!prevResult) {
          return false
        }
        // previous one was valid, let's check for current validator and return the result
        const [valid, err] = validatorFn(formData[key], key, formData, form.current)
        if (!valid) {
          error = err
        }
        return valid
      }, true)

      acc[key] = validity;
      return acc;
    }, {})

    if (Object.keys(isValid).length) {
      const errField = Object.keys(isValid)[0]
      inputWithError.current = errField
      const field = getField(errField)
      if (!field) {
        return
      }
      field.setCustomValidity(error);
      field.reportValidity();
    }
  }

  return (
    <form className="form" ref={form} onSubmit={onSubmit}>
      {FIELDS.map((field) => (
        <Input
          key={field.name}
          field={field}
          registerField={registerField}
          onChange={handleChange}
        />
      ))}
      <button type='submit'>Submit</button>
    </form>
  )
}

A lot is going on in the above Form Component, let’s try to break it down by taking a look at each block of code

...
const form = useRef(null)
const inputWithError = useRef(null)
const fieldRefs = useRef({})
...

This block is creating refs to keep some information between renders of the Form. The most important one is the one named fieldRefs

This ref will collect all the refs of HTML5 Input elements like input, select, radio, checkbox etc.

And inputWithError will keep the lat field where the error was present

...
const registerField = (key, ref) => {
  fieldRefs.current = {...fieldRefs.current, [key]: ref}
}
...

This function above will be passed down to the renderers to register the input element to the fieldRefs collection.

...
const getField = (key) => {
  return (
    Array.isArray(fieldRefs.current[key].current)
      ? fieldRefs.current[key].current[0]
      : fieldRefs.current[key]
  ).current
}
...

Now this function named getField is gonna help us retrieve the Fields based on their names.

We need this function because we will need some logic while accessing the fields. That’s why it is better to keep the field access simplified in one place.

...
const resetError = (errorFieldKey) => {
  if (errorFieldKey) {
    const field = getField(errorFieldKey)
    if (!field) {
      return
    }
    field.setCustomValidity('');
    field.reportValidity();
  }
}
...

Now, this function will be handy to reset the error on any Field.

...
const handleChange = (key, ...args) => {
  resetError(inputWithError.current)
}
...

We will be passing this function down to the renderers to react to any change in the Fields. In the current use case, the only reaction we need is clear the errors if present.

...
const customValidations = FIELDS.reduce(
  (acc, field) => field?.validations
    ? {...acc, [field.name]: field.validations}
    : acc
  , {}
)
...

The above block will prepare aa subset of the collection to keep track of any needed custom validation to run. This collection will be handy in the submit method when we need to find the needed validations.

Next is our Form Submit Handler with signature:

...
const onSubmit = (e) => {
  e.preventDefault()
  ...
}
...

In this submit handler we perform some actions to make sure our Form Data is valid. Let’s take a look at the contents of the submit function.

...
const onSubmit = (e) => {
  e.preventDefault()
  if (inputWithError.current) {
    resetError(inputWithError.current)
  }

  if (!form.current.checkValidity()) {
    return false;
  }
  ...
}
...

There are two things in the above code block.

First is to clear the custom errors with inputWithError.current ref and resetError function.

Second is to check the validity of the Form with form ref and checkValidity function from HTML5 validation API

...
const formData = serialize(new FormData(form.current))

let error = null
...

Next, we prepare the Form Data as an object of form element names as keys and their values. We will do so with the help of FormData API and serialize function.

The serialize function looks like the following:

export default function serialize (formData) {
  const values = {};
  for (let [key, value] of formData.entries()) {
    if (values[key]) {
      if ( ! (values[key] instanceof Array) ) {
        values[key] = new Array(values[key]);
      }
      values[key].push(value);
    } else {
      values[key] = value;
    }
  }
  return values;
}

We had discussed the FormData in the following post. The serialize function above is also borrowed from the said post:
FormData API: Handle Forms like Boss 😎 - Time to Hack

After serializing the data, we need to run the validations. The following Code Block in the Form Submit method will be doing so:

...
// Check for custom validations
const isValid = Object.keys(customValidations).reduce((acc, key) => {
  const validations = customValidations[key]
  const validity = validations.reduce((prevResult, validatorFn) => {
    // short circuit the validations if previous one has failed
    if (!prevResult) {
      return false
    }
    // previous one was valid, let's check for current validator and return the result
    const [valid, err] = validatorFn(formData[key], key, formData, form.current)
    if (!valid) {
      error = err
    }
    return valid
  }, true)

  acc[key] = validity;
  return acc;
}, {})
...

The above function works in fail-fast strategy. Any encounter of failed validation will make the whole Block result in invalid. And the failure will mark the field name and error message.

And then the last part of the Font submit function is:

...
if (Object.keys(isValid).length) {
  const errField = Object.keys(isValid)[0]
  inputWithError.current = errField
  const field = getField(errField)
  if (!field) {
    return
  }
  field.setCustomValidity(error);
  field.reportValidity();
}

Here if any error is preset after checking through the validator functions, we will set the custom Error. setCustomValidity for setting custom error and reportValidity to show it to the user

And that’s how we do the Simple and Fast forms in React by leveraging the Browser APIs.

Conclusion

The form will always be a pain if we try to do all things by ourselves. But Browser has pretty strong APIs to help you build the needed Form Validation.

We saw how to build customizable Forms and Do Custom Validations with HTML5.

What is or was your concern with Forms? Let’s try to fix it together.

Let me know through comments 💬 or on Twitter at @patel_pankaj_ and/or @time2hack

If you find this article helpful, please share it with others 🗣

Subscribe to the blog to receive new posts right to your inbox.

Credits

Icons from IconFinder, [2], [3]

Originally published at https://time2hack.com on December 15, 2020.

Where do you initialize state in React Component?

Pankaj Patel — Thu, 05 Nov 2020 09:16:35 +0000

Functional Components are super cool. Though, Classical components are still used & so is the conventional state in those.

State initialization is a very common scenario while developing the components.

But where do you initialize your components’ state?

Let’s looks at the places where it could be initialized.

The obvious constructor

One obvious place to initialize is the constructor of the component. Similar to the following:

class Contacts extends React.Component {
  // ...
  constructor(props) {
    super(props)
    this.state = {
      isLoading: false,
      contacts: [],
      errors: []
    }
  }
  // ...
}

Pros:

Very visible and verbose
Can access props to determine the new state

Cons:

Unnecessary use of super and constructor
Can use props but most of the time it is not needed

The Class property way

class Contacts extends React.Component {
  // ...
  state = {
    isLoading: false,
    contacts: [],
    errors: []
  }
  // ...
}

Pros:

Follows the OOP style of the property declaration
Verbose

Cons:

Can’t use props for initialisation
Less readable for to those who prefer old-style JS

Arguments

Consistency

If you are using one style, you should follow the same style everywhere. As the software will always be evolving, consistency should not block you from writing better code.

Readability

Expecting some pieces of code to be there. Is state is there, I would expect it to be in the constructor or at the beginning of the component. Readability is subjective and prone to habitual needs.

Tools

Modern dev toolchain in Front End will allow you to write small and readable code. And with transpiling (transform + compile), it will be usable for all Browsers.

Using tools at disposal will bring more creative ways to solve problems.

Legacy Code

If the code is Legacy and is stopping you to write better code, it’s time to. Refactor.

ReactJS Specific Reasons

Start thinking about Functional Components and Hooks

const Header = props => (
  <header>
    <h1>Title</h1>
    <strong>SubTitle</strong>
  </header>
)

Keep the state minimal, try to move the state to parent and use a prop to pass it down
Stateless components are Better as they are better testable

const Button = props => {
  const [disabled, setDisabled] = useState(false)
  return (
     <button
       disabled={disabled}
       onClick={() => setDisabled(prev => !prev)}
     >
       {props.text}
     </button>
  )
}

// can become
const Button = props => (
   <button
     disabled={props.disabled}
     onClick={props.setDisabled}
   >{props.text}</button>
)

Compose Components from Props

const Button = props => (
   <button
     disabled={props.disabled}
     onClick={props.setDisabled}
   >{props.spinner}{props.text}</button>
)

// can become
// children will hold spinner
// & parent can decide when to show/hide spinner
const Button = props => (
   <button
     disabled={props.disabled}
     onClick={props.setDisabled}
   >{props.children}</button>
)
const App = () => {
  const [loading] = false
  return <Button>
    {loading && <Spinner />}
    <span>Click me</span>
  </Button>
}

Use DefaultProps in case of Class components
Use prop destructuring along with Default Values for Functional components

const Button = ({
  disabled = false,
  setDisabled = () => {},
  children = null
}) => {
  if (!children) {
    // Dont render without any Button content
    return null 
  }
  return (
    <button
      disabled={disabled}
      onClick={setDisabled}
    >{children}</button>
  )
}

Conclusion

A small thing to ask where to initialise the state. But in a large codebase, these decisions will improve your daily code efficiency.

What style do you prefer?

Let me know through comments 💬 or on Twitter at @patel_pankaj_ and/or @time2hack

If you find this article helpful, please share it with others 🗣

Subscribe to the blog to receive new posts right to your inbox.

Credits

Photo by Ferenc Almasi on Unsplash

Originally published at https://time2hack.com on Nov 4, 2020.

5 Tips for Component Based Development

Pankaj Patel — Sat, 19 Sep 2020 15:33:19 +0000

Component-based Development has taken the FrontEnd Development by storm.

And Components not being any language standard, there are many ways to Create and Use Components.

Here are some tips to help you with Component Driven Development.

These are not limited to modern frameworks like Angular, VueJS, React. These tips will help in any Component Driven Development/Setup.

Composition

Try to imagine a component (A) having three Child Components (A1, A2, A3). Each of them need different data to render.

And for all three child components, you need to pass data through Parent Component.

const App = () => {
  const dataA = {}, dataB = {}, dataC = {};
  const handleClickA = () => {};
  const handleClickB = () => {};
  const handleClickC = () => {};

  return (
    <ComponentA
      dataA={dataA}
      handleClickA={handleClickA}
      dataB={dataB}
      handleClickB={handleClickB}
      dataC={dataC}
      handleClickC={handleClickC}
    />
  );
}

const ComponentA = ({
  dataA,
  dataB,
  dataC,
  handleClickA,
  handleClickB,
  handleClickC
}) => (
  <>
    <ComponentA1 data={dataA} handleClick={handleClickA} />
    <ComponentA2 data={dataB} handleClick={handleClickB} />
    <ComponentA3 data={dataC} handleClick={handleClickC} />
  </>
);

With composition, you can rewrite the above arrangement as:

const App = () => {
  const dataA = {}, dataB = {}, dataC = {};
  const handleClickA = () => {};
  const handleClickB = () => {};
  const handleClickC = () => {};

  return (
    <ComponentA>
      <ComponentA1
        data={dataA}
        handleClick={handleClickA}
      />
      <ComponentA2
        data={dataB}
        handleClick={handleClickB}
      />
      <ComponentA3
        data={dataC}
        handleClick={handleClickC}
      />
    </ComponentA>
  );
}

const ComponentA = ({children}) => (
  <>
    <h1>Hello world</h1>
    {children}
  </>
);

Extract complex logic as functions

Any complex logic that can take an input and provided an output should be extracted as functions. Benefits to extract logic as function are:

Testable Functions
Better Code reusability
Components stay small
Easy for Code Review
Components only need to be tested for interactivity

Utilise CSS for common stuff

Functionalities like Hover actions, basic animations look very lucrative achieve with JavaScript. But consider achieving these functionalities in CSS itself.

CSS can achieve some functionalities very easily as compared to JS. Use CSS to your benefit.

const App = () => {
  const [hovered, setHover] = useState(false)
  return (
    <Component
      className="container"
      onMouseEenter={() => setHover(true)}
      onMouseEenter={() => setHover(false)}
    >
      <Contact hovered={hovered} />
    </ComponentA>
  );
}

const Contact = ({hovered}) => {
    if (!hovered) {
    return null
  }

  return (
    <a href="mailto:info@time2hack.com">Contact Us</a>
  );
}

You can rewrite above components as:

const App = () => {
  const [hovered, setHover] = useState(false);

  return (
    <Component
      className="container"
      onMouseEenter={() => setHover(true)}
      onMouseEenter={() => setHover(false)}
    >
      We provide User Interface Development Services
      <Contact className="contact-link"/>
    </ComponentA>
  );
}

const Contact = () => (
  <a href="mailto:info@time2hack.com">Contact Us</a>
);

With styles defined in SCSS as:

.container {
  display: block;

  .contact-link {
    display: none;
  }

  &:hover .contact-link {
    display: block; /* or any other visible display */
  }
}

With this way, re-render of component is not needed.

Separation of Concern

Code blocks should only do what they were intended to do.

Adding more conditions and parameters can make them lengthy and hard to debug and test.

Take for example from the code block above, the ContactUs component,

const Contact = ({hovered}) => {
  if (!hovered) {
    return null
  }

  return (
    <a href="mailto:info@time2hack.com">Contact Us</a>
  );
}

Here it is more dependent on hovered prop values for render. Which means this Component needs testing for the various cases of hovered prop.

In this case, it is a boolean prop but it will multiply in case of complex object props.

We can rewrite the component to remove the dependency on the hovered prop.

The Container component should own the concern of render/no-render with itself.

Contact Component’s job is to render Contact Us button/link. Expecting it to do more logical things will introduce more edge cases.

We can either use CSS to handle hide and show the button on Hover; as we saw in the previous section.

Or, conditionally render Contact component from the parent component, which is as follows:

const App = () => {
  const [hovered, setHover] = useState(false);

  return (
    <Component
      onMouseEenter={() => setHover(true)}
      onMouseEenter={() => setHover(false)}
    >
      We provide User Interface Development Services
      {hovered && <Contact />}
    </ComponentA>
  );
}

const Contact = () => (
  <a href="mailto:info@time2hack.com">Contact Us</a>
);

Use tools at the disposal

Design Systems, Storybook, unit tests, coverage reports etc. I can go on and list many more tools. But the take away here is “Identify the key tools and get the best out of them”

For example,

Storybook

Storybook is a great tool for building the basic examples and possible combinations. It also helps to build the documentation of Components.

Testing

Unit, Integration, E2E etc. will help you Code and Release with Confidence. Disperse your testing in various strategies and keep it sane.

Test cases provide awesome documentation around restrictions and edge cases. Cover your Code with Tests and Maintain them.

You can use Coverage Reports to get Overview on how much Testing has increased and add Coverage Report labels to PRs on Github

Linters

Linters will help you write beautiful code and address syntax/code style propblems. These problems usually appear in code reviews if not take care while development.

Style Rules like spacing, code style, function signatures etc are common review comments. Avoiding them from start will help in efficient for Code Reviews.

Bonus 😎

Code for People 🤝

Code for application is easy. Code for people is very hard.

Code can be very optimized and hard to read at the same time. Hard to read code can make it prone to much common error related to misunderstanding the code.

Keeping the Lines Small, Easy to Read can lead to better code harmony.

I came across the argument of having a more disciplined team towards Code Structure. This argument is very valid but the code should also be ready for new joiners, be it for Senior Devs to Junior Devs.

Team discipline can be different from the general community discipline. That’s why, Team discipline & community discipline should be with least friction.

Try to follow some widely used Code Styles like

Conclusion

With above tips, we can derive a better Front End Code.

What challenges did you face while doing Component Driven Development?

Let me know through comments 💬 or on Twitter at @patel_pankaj_ and/or @time2hack

DEV Community: Pankaj Patel

Too many useState? Let's useReducer!

useReducer

Parameters

Reducer Function

Initial State

Returned Values

Derived state

Dispatch Function

Benefits of useReducer

Testability

Modularity

Readability

Conclusion

Can I use hover on Touch Devices?

Current Challenge

Solution

Hover in JS?

Conclusion

Ways to convert String to Number in JS

parseInt

parseFloat

Number

Unary Operators

Unary Plus

Unary Minus

Binary Operators

3 Must haves for Merge Requests for swift Code Review

1. Title

2. Brief Description

3. Related Ticket/Issue

Conclusion

When NOT to choose Next.js

Existing Codebase

Runs on Node.js server

API Routes

Refactoring Effort

CDN

TIL: cache-control is as inconsistent as it can get in different Browsers

Fixing WebpackChunkName for Dynamic Imports

Conclusion

Bonus tip

Credits

Gatsby or Next.js?

🚦 Submitting a Form to different Actions in HTML5

Problem

Solution

Benefits

Concerns

time2hack / multi-action-forms-example

Conclusion

Credits

Building Fast Forms in React with HTML5 & Validations

Checkbox

Radio

Select

And with the validations of HTML5, it will trigger the errors until the Form is completely filled.

Conclusion

Credits

Where do you initialize state in React Component?

The obvious constructor

Pros:

Cons:

The Class property way

Pros:

Cons:

Arguments

Consistency

Readability

Tools

Legacy Code

ReactJS Specific Reasons

Conclusion

Credits

5 Tips for Component Based Development

Composition

Extract complex logic as functions

Utilise CSS for common stuff

Separation of Concern

Use tools at the disposal

`useReducer`

Derived `state`