DEV Community: Time to Hack

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.

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

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

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

Credits

Expansion, game, puzzle, solution icon
Photo by UX Store on Unsplash

Originally published at https://time2hack.com on Sep 19, 2020.

Getting started with Eleventy (11ty)

Pankaj Patel — Fri, 11 Sep 2020 08:11:07 +0000

JAMStack is Fast. Fast for Development and to deliver ultra Fast websites.

To develop with JAMStack, one of the ways is Static Site Generation.

Static Site Generators (SSG)

SSGs are the tools which will take the data from any data source and generate Static HTML pages.

Static Sites are way faster than any dynamic site because:

No content generated on runtime, which means no time spent in this process
The server doesn’t have to match for the dynamic URLs. HTML files delivered straight to the browser without any Route/URL matching
As the content is Static, it will be cached for longer time
Again, being Static, the websites can be delivered through CDNs. This way users don’t have to wait very long for the response.

And to build WebSites with SSGs, Eleventy (11ty) is fast and easy to use the tool.

Eleventy (11ty)

11ty is a JavaScript alternative of Jackyl. It’s built with no-configuration in mind. Though, it supports many templating languages; for example MarkDown, Pug, Handlebars etc.

We will make a simple Blogging website with following features in consideration:

Index Page with
- Blog Intro
- List of Posts
Blog Post page
Tags with Tag Index
Comments with Disqus
Deployed on Netlify

First, we need to create a Project and add 11ty as the dev dependency, lets do that with following commands:

# make project directory
mkdir awesome-blog

# switch to the project directory
cd awesome-blog

# initialize the Node Project
yarn init -y

# Add 11ty as a dev dependency
yarn add -D @11ty/eleventy

# open VS Code in the directory
# (if you use VSCode and have set up CLI command)
code.

Now we edit the package.json file to add the following to the scripts:

{
  ...
    "scripts" : {
    "start" : "eleventy --serve"
  },
  ...
}

After adding start script in the package.json, launch yarn start on the root of your Project directory from CLI.

Now that 11ty is up and running, we need to add some content to see it building.

By default, 11ty will output the generated HTML files in _site directory.

Let's go ahead and create out index page with index.md file in the root of the project as:

# Hello World
---
Welcome to the `awesome-blog`

Which will get generated as the following body in _site/index.html:

<h1>Hello World</h1>
<hr>
<p>Welcome to the <code>awesome-blog</code></p>

Well, that was super simple; and blank with no CSS. Let's try to add some Style by adding Bootstrap CSS.

But where do we add them? This is where layouts in the 11ty come into the play.

As the name suggests, Layouts are the Page Generator Templates where the data can be filled by selected page.

The layouts must be inside the _includes directory.

Lets try to make a Handlebar layout as home.hbs for the home page:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>{{ title }}</title>
  <link rel="stylesheet" href="//stackpath.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css" />
</head>
<body class="p-3">
  <div class="container">
    {{{content}}}
  </div>
</body>
</html>

To use the above template, we need to add some context to our markdown file. We will add the context with the FrontMatter format inside the markdown.

FrontMatter is the data format go git more contextual data about the file. For a blog post, it can be title, tags etc. For a landing page, it can be with Sections, Images and other blocks of information.

For our markdowns, we will add title and tags in the front matter all the time and use it in our layouts.

So with decided FrontMatter, here is our index.md:

---
layout: layouts/home.hbs
title: Hello World
tags: [intro, random, gif]
---
# Hello World

---

Welcome to the `awesome-blog`

Here we will add some awesome gifs rolling around the internet.

Starting with this:

![me thinking 'I can do this'](https://media.giphy.com/media/YTJXDIivNMPuNSMgc0/giphy-downsized.gif)

Now we have Title repeating two times, we will keep the FrontMatter and remove form the content of the markdown to make it as follows:

---
layout: layouts/home.hbs
title: Hello World
banner: https://placeimg.com/1000/480/nature
tags: [intro, random, gif]
---
Welcome to the `awesome-blog`

Here we will add some awesome gifs rolling around the internet.

Starting with this:

![me thinking 'I can do this'](https://media.giphy.com/media/YTJXDIivNMPuNSMgc0/giphy-downsized.gif)

And with this, we will update our layout as following inside the body:

<body class="p-3">
  <div class="container">
    <h1>{{title}}</h1>
    {{#if banner}}
      <img src="{{banner}}" alt={{title}} />
    {{/if}}
    {{#if tags}}
      <div class="tags">
        {{#each tags}}
          <div class="badge badge-dark">{{this}}</div>
        {{/each}}
      </div>
    {{/if}}
    <hr />
    {{{content}}}
  </div>
</body>

Now with basics in mind, we want to make the blog posts and make all the posts listed on the homepage.

In 11ty, by default, the HTML files will be generated in the same directory structure as of the data file. And the URLs will be like the data file-names.

So, in our case, we can make all the posts inside the posts directory with post slug as the file-names

And our Markdown files will follow the following structure:

/
├── index.md
└── web
    ├── hello-world.md
    ├── ...
    └── trip-to-new-york.md

Now we need to add these post lists in the Home Page.

For this, let’s make a rough try making the data of post in the FrontMatter of the Home Page and create a new layout for it.

For the list of post, I will approach the data of front matter as follows:

title: Home
posts:
- 0:
  title: Hello World
  url: posts/hello-World/
  banner: //source.unsplash.com/user/pankajpatel/1024x400
- 1:
  title: Random Post
  url: posts/random/
  banner: //source.unsplash.com/user/pankajpatel/likes/1024x400

And the layout can be change to the following:

<body class="p-3">
  <div class="container text-center">
    <h1 class="m-5">{{title}}</h1>

    {{#if posts}}
      <div class="row">
        {{#each posts}}
          <a class="col mb-3 text-decoration-none" href={{this.url}} data-index={{@key}}>
            <article class="card" href={{this.url}} data-index={{@key}}>
              <img src="{{this.banner}}" class="card-img-top" alt="{{this.title}}">
              <div class="card-body text-left">
                <h1 class="card-title font-weight-light">{{this.title}}</h1>
                <p class="card-text"><small class="text-muted">Last updated 3 mins ago</small></p>
              </div>
            </article>
          </a>
        {{/each}}
      </div>
    {{/if}}
    <hr />
  </div>
</body>

But this FrontMatter data were prepared manually. What can we do to build it automatically?

It’s time to get our hands dirty with configuration files.

For 11ty, the config file is .eleventy.js

In 11ty’s config file, there needs to be one exported function. This function accepts the current eleventyConfig.

The current eleventyConfig has some API methods to define different behaviours like:

Adding/Modifying collection
Adding new filters
etc

For us, the concerned part is to add a new collection for our posts and use this collection to list the posts on the homepage.

To get the collection of all the posts, we had created FrontMatter data type. And for all the posts, we set the type as post

Now our 11ty config looks like the following:

module.exports = (eleventyConfig) => {
  eleventyConfig.addCollection("posts", (collection) => {
    return collection.getAll().filter((item) => {
      return 'type' in item.data && item.data.type === 'post'
    })
  })
}

Now with above added posts collection, we can update our homepage template as:

<body class="p-3">
  <div class="container text-center">
    <h1 class="m-5">{{title}}</h1>

    {{#if collections.posts}}
    <div class="row">
      {{#each collections.posts}}
      <a class="col mb-3 text-decoration-none" href={{this.data.page.url}} data-index={{@key}}>
        <article class="card" href={{this.data.url}} data-index={{@key}}>
          {{#if this.data.banner}}
            <img src="{{this.data.banner}}" class="card-img-top" alt="{{this.data.title}}">
          {{/if}}
          <div class="card-body text-left">
            <h1 class="card-title font-weight-light">{{this.data.title}}</h1>
            <p class="card-text"><small class="text-muted">Last updated 3 mins ago</small></p>
          </div>
        </article>
      </a>
      {{/each}}
    </div>
    {{/if}}
    <hr />
  </div>
</body>

Now that our homepage and posts are ready, we can publish it.

To publish our site, first, we need a git repository and commit the changes.

git init
echo "node_modules\n_site" > .gitignore
git add .
git commit -m "🚀 personal blog launch initiated"

Now you have committed the code on your local repo. You can create a repository on GitHub and add remote to your local repo. Then you can push your branch and it is available remotely.

Now it is time to publish our blog through this repository.

Following are the way to publish the website:

Publish on Netlify

Netlify publish is a matter of a few clicks.

Log into Netlify with Github from here: Netlify App
Click on New Site from Git button
Connect to your Github if not connected
Select the repo that you had before created
Netlify will detect the type of Project and will suggest a build command
Click on Deploy Site
Yous site is deployed

You can watch the following video to see the above steps in action

11ty on Netlify - YouTube

Publish on GitHub Pages

To publish on GitHub pages, you need to add build script to your package.json

You can do so by adding following line the scripts:

{
  ...
    "scripts" : {
    "build" : "eleventy",
    "start" : "eleventy --serve"
  },
  ...
}

Now that the build script is added. We need to add GitHub action to Auto Publish our site to Github Pages. Following is the YAML file placed at .github/workflows/publish.yaml

name: publish

on:
  push:
    branches:
      - master

jobs:
  deploy:
    runs-on: ubuntu-18.04
    steps:
      - uses: actions/checkout@v2

      - name: Setup Node
        uses: actions/setup-node@v1
        with:
          node-version: "12.x"

      - name: Get yarn cache
        id: yarn-cache
        run: echo "::set-output name=dir::$(yarn cache dir)"

      - name: Cache dependencies
        uses: actions/cache@v1
        with:
          path: ${{ steps.yarn-cache.outputs.dir }}
          key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-yarn-

      - name: Installing Dependencies
        run: yarn install

      - name: Building App
        run: yarn build

      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./_site

Now you need to enable the GitHub pages from your repository’s Settings.

Now commit and push the above file. This will trigger the build and publish the site

Conclusion

11ty is loved and recommended by many people. And after using it for a while, I also think that it is by far the simplest Static Site Generator.

What do you think?

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 Andrew Neel on Unsplash

Originally published at https://time2hack.com on Sep 11, 2020.

Are you using Trailing Commas in your JavaScript?

Pankaj Patel — Wed, 02 Sep 2020 09:50:15 +0000

I am presuming that you are using objects and arrays every day in your JavaScript.

And I am also sure that most of them are not single line these arrays and objects with items spread in many lines.

Though my question here is:

Do you leave a trailing comma at the end of the last item before closing the object or array creation?

If you are not using any trailing commas then why not?

Let’s start with Why trailing comma could help you

Reasons to keep Trailing Comma

No False diff counts

The Commit Messages are gonna be of exactly the line when you add or remove items i.e. no false diff counts 🤥

  const ACTIONS = {
    ADD_ITEM: 'ADD_ITEM',
-  UPDATE_ITEM: 'UPDATE_ITEM'
+  UPDATE_ITEM: 'UPDATE_ITEM',
+  DELETE_ITEM: 'DELETE_ITEM'
  }

Here we have diff count of +2-1
OR

const ACTIONS = {
  ADD_ITEM: 'ADD_ITEM',
  UPDATE_ITEM: 'UPDATE_ITEM',
+ DELETE_ITEM: 'DELETE_ITEM',
}

And here we have diff count of +1

Which one do you prefer to in the Pull/Merge Requests?

New items always in the end

We can add new items at the end of the Object or Array, rather than being in middle to avoid multiline changes 👻

Considering the above example, we would have to add the new item in the middle of the object to keep the edit count as 1 Line

const ACTIONS = {
    ADD_ITEM: 'ADD_ITEM',
+ DELETE_ITEM: 'DELETE_ITEM',
  UPDATE_ITEM: 'UPDATE_ITEM'
}

Or we can have trailing commas and add the new item at the end of the object all the time

const ACTIONS = {
  ADD_ITEM: 'ADD_ITEM',
  UPDATE_ITEM: 'UPDATE_ITEM',
+ DELETE_ITEM: 'DELETE_ITEM',
}

No Fear of Breaking Production

Transpilers and Bundlers are will omit trailing comma and not break the production 😉

The modern browser will not complain about the trailing commas as it is part of the ES5 standard

But the old browser might complain and for that case, before IE9.

Even though finding such an old browser is a good expedition. We can enable our bundlers to omit the trailing commas from production bundles so that it is safe to ship.

For that old browser, the trailing comma would be the least of the problems. It is because the old browsers’ capability to parse and run large JS apps is also questionable.

Use babel-plugin-syntax-trailing-function-commas in babel configuration to enable trailing commas in your JavaScript source code.

If you are using Prettier, you can configure with following:

trailingComma in.prettierrc
--trailing-comma if using Prettier via CLI

Possible values are:

es5 only on arrays and objects
none nowhere, no trailing commas
and all everywhere possible; arrays, objects, function params etc

Biases

Looks like something is missing

I have heard this argument many times. If there is a trailing comma, it feels like something is missing or it is wrong.

You will get used to it.

We have got used to writing HTML in JS, trailing comma is a very small thing in front of it.

Why extra character for nothing?

This comma is an extra character which is not useful for any execution.

We write code in Clean way for other developers to understand.

Machines can understand comma or no-comma in the same way. Then why not help the other developers in reviewing the code.

References

javascript - Are trailing commas in arrays and objects part of the spec? - Stack Overflow

Conclusion

The benefits of trailing comma are less though very good to have.

What do you think about trailing commas?

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 Sep 1, 2020.

Now you can manage Aliases for FrontEnd Workflow at one place

Pankaj Patel — Wed, 26 Aug 2020 14:24:45 +0000

Aliases are very handy; be it in CLI or in FrontEnd development.

In previous post, we had seen the benefits of Aliases in Webpack

But what about other bundlers like Rollup? Or Test environment like Jest?

Problems

Fragmentation

In different tools, there is a different way to define aliases and this makes tricky to define and maintain the aliases.

Source of Truth

Another trouble is to maintain a single source of truth for the Aliases, as this configuration is everywhere, who gets to become the source of truth.

Onboarding Experience

Also for new joiners of Team, its hard to wrap the head around aliases once you are using them everywhere.

Manual Knowledge

These many configurations are Manual Knowledge because

Has to be maintained manually
Documentation is spread around and can easily go out of sync
Once the person who introduced aliases is gone, it starts falling apart

Solution

To solve the above mentioned problems, here is Alias-HQ

Alias-HQ picks up the configuration style of TypeScript Config (tsconfig.json) or VSCode Project Config (jsconfig.json)

And from those configs allows plugin style usage and manipulation of the aliases

And once the aliases configs are in place, you can imply import those aliases in your Bundler or Test setup scripts.

Lets consider following jsconfig.json:

{
  "compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "@components/*": ["components/*"],
      "@assets/*": ["assets/*"],
      "@config/*": ["config/*"]
    }
  }
}

Now with the above project config, you can add aliases to your webpack in webpack.config.js as:

const aliases = require('alias-hq')

module.exports = {
  ...
  resolve: {
    alias: aliases.get('webpack')
  }
  ...
}

For rollup in rollup.config.js as:

import alias from '@rollup/plugin-alias';
import aliases = require('alias-hq')

module.exports = {
  ...
  plugins: [
    alias({
      entries: aliases.get('rollup')
    })
  ]
};

Or jest in jest.config.js

import aliases from 'alias-hq'

module.exports = {
  ...
  moduleNameMapper: aliases.get('jest'),
}

If are configuring Jest through package.json, you have to move to jest.config.js to be able to use AliasHQ for dynamic alias mapping generation

What about using aliases in Create React App?

To customise CRA, you need to use some packages which will tap into the configs from CRA. Though CRA does not recommend it and might break.

Such packages are:

Another way is to eject the configs to take full control over the Bundling and Testing configuration.

I tried to tap into webpack and jest configs with react-app-rewired, and this is my config to allow overrides and inject aliases:

// config-overrides.js
const aliases = require('alias-hq')

module.exports = {
  // The Webpack config to use when compiling your react app for development or production.
  webpack: (config, env) => ({
    ...config,
    resolve: {
      ...(config.resolve || {}),
      alias: {
        ...(config.resolve.alias || {}),
        ...aliases.get('webpack')
      }
    }
  }),
  // The Jest config to use when running your jest tests - note that the normal rewires do not
  // work here.
  jest: (config) => ({
    ...config,
    moduleNameMapper: {
      ...(config.moduleNameMapper || {}),
      ...aliases.get('jest')
    }
  })
}

With alias path configs in jsconfig.json as:

{
  "compilerOptions": {
    "baseUrl": "./src",
    "paths": {
      "@components/*": ["components/*"],
      "@reducers/*": ["reducers/*"],
      "@helpers/*": ["helpers/*"]
    }
  }
}

But what about TypeScript Project?

Though if you are using TypeScript, the configuration for alias-hq are picked up from tsconfig.json, so you need to add the path settings to tsconfig.json as:

{
  "compilerOptions": {
    ...,
    "baseUrl": "./src",
    "paths": {
      "@components/*": ["components/*"],
      "@reducers/*": ["reducers/*"],
      "@helpers/*": ["helpers/*"]
    }
  },
  ...
}

In some cases, the configuration of paths might be invalid and get removed automatically.

In such case, you will need to make a base config for TypeScript compiler and extend the main config with the base config

// tsconfig.base.json
{
  "compilerOptions": {
    ...,
    "baseUrl": "./src",
    "paths": {
      "@components/*": ["components/*"],
      "@reducers/*": ["reducers/*"],
      "@helpers/*": ["helpers/*"]
    }
  },
  ...
}

And the main config of TypeScript Compiler looks like:

// tsconfig.json
{
  "extends": "./tsconfig.base.json",
  "compilerOptions": {}
}

Conclusion

Here we learned how to use AliasHQ to add aliases to

Webpack
Rollup
Jest
Create React App

How do you manage your aliases?

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