DEV Community: Amandeep Singh

Thinking about accessibility—a few tips to make a difference

Amandeep Singh — Sun, 20 Jun 2021 06:47:29 +0000

While conducting an interview session, I asked a candidate about what web accessibility is, the answer was, "Isn't it about aria-label?". It made me smile. It wasn't an unexpected answer. I have experienced the same replies many times while bringing this topic up casually over a cup of coffee chat.

I know where the root problem lies. I believe it's the lack of awareness and knowledge about accessibility in general. It's a mindset that we consider accessibility as an optional thing. Web accessibility is rarely seen as a part of acceptance criteria when writing Jira tickets.

Well, being a web developer, we can change this mindset. We can educate ourselves, spread awareness, share the guidelines. Together we can make the web more inclusive and accessible.

With the motivation aside, It's time to look into a few tips that can quickly get you up and running with accessibility in mind. After all, it's not that scary as you might have thought. Time to make a difference.

Use Semantic elements
Don't use divs for creating a button
Use 'skip to main content' link
Don't forget the focus state
Never miss the 'alt' tag on your image
Link text should describe the purpose of the link
No ARIA is better than Bad ARIA
Implementing your custom UI widgets
Use ‘lang’ attribute to define the language of the page, and element
Use jest-axe to automate your a11y tests
Use CSS to highlight the accessibility issues
Using Icon only as button
VisuallyHidden React component
Color contrast
Accessibility checklist
Learn to operate VoiceOver on your Mac
Use a11y eslint plugin as your dev dependency
Use ARIA live regions to announce dynamic changes in the page
Zoom up the page to 200% and see if you can still use the website
Chrome/FireFox extensions
Read articles on accessibility, follow blogs/newsletters
It’s not only about the UI

Use semantic elements where possible

Semantic elements are the ones that convey meaning to both the browser and the developer.
They have some intrinsic role associated with them.
Screen readers would announce their role to help visually impaired users navigate a page.
The VoiceOver rotor in mac can list available landmarks, links, headings if the semantics elements are used.
Improves the page search ranking SEO.
References:
- Semantic elements
- Accessibility Through Semantic HTML

Don't use divs for creating a button

div is not a semantic element, it doesn't convey anything to the browser. It's also non-interactive.
Adding a role="button" is not enough; it won't make it keyboard accessible.
You need to add tabindex="0" to make it focusable.
The button element gets you all the aforementioned features for free.
References: Use button instead of divs

Use 'skip to main content' link

For users with some motor disabilities, it can be hard to navigate every link item before reaching the main content block.
Using the skip to main content link allows the users to skip the long navigation links, and land straight to the main content.
Put the skip to main content link at the top of the page, so that it can receive focus when the Tab key is hit.
References:

Don't forget the focus state

Focus indicator helps users figure out where they are on the page.
It also benefits the users with short-term memory to discover where the focus is located.
If you're setting outline: none for the focus state, make sure to style this state to make focus clear and visible.
Aid in keyboard navigation as you can see a focus ring around interactive elements when tabbing.
You can style the focus ring to improve aesthetics; it doesn't have to be ugly.
Can use :focus-visible
References:

Never miss the 'alt' tag on your image

Every image that has a semantic meaning should have a non-empty alt attribute value.
If the image is used for presentational purposes only (Background gradient), you need to pass alt="" value.
Skipping the alt tag is not an option at all.
References:
- Five Golden Rules for Image alt
- Image Accessibility checklist

Link text should describe the purpose of the link

It's like your promise to the users. Screen reader users rely on some shortcuts to bring up the links available on your page.
Link text shouldn't be ambiguous. For example, click here as link text conveys no meaning. Use meaningful description text.
Shouldn't be too long. Long text can be hard to comprehend/remember and might miss conveying the actual purpose of a link.
References: link text purpose (WCAG)

No ARIA is better than Bad ARIA

Assistive technologies rely on the aria roles of the elements to convey semantics. It's kind of a promise.
Using a bad aria role can cause more harm than good. So choose it wisely.
Moreover, you don't need to use a role while using semantic elements. Mostly all semantic elements have implicit roles.
References:
- No ARIA is better than Bad ARIA
- ARIA Design Pattern Examples

Implementing your custom UI widgets

If you're implementing your own custom UI widget (e.g Modal/Tabs), I'll highly recommend reading WAI-ARIA Authoring Practices and WCAG Techniques.
This will help you to make informed decisions and avoid basic a11y issues.
Take inspiration from open source libraries that take pride in keeping accessibility as their core feature. Reach UI, Chakra UI, Mentine, Reakit are some of the examples.
References
- WAI-ARIA Authoring Practices Guide
- WCAG Techniques.

Use 'lang' attribute to define the language of the page, and element

Make sure to use <html lang='prefered-language-of-your-users'>. For example, <html lang="en"> would set the language to English.
Allow assistive technologies such as screen readers to invoke the correct pronunciation.
References:
- language tag syntax mdn
- WCAG guidelines

Use jest-axe to automate your a11y tests

If you're using jest, it's easy to automate the findings of basic a11y issues via jest-axe.
For example, in React, you can create a test utility function like the following:

 import { axe } from 'jest-axe';

 /*
 * @param {object} ui element
 * @param {object} axeOptions jest-axe options
 */
const testA11y = async (element, axeOptions = {}) => {
  const container = React.isValidElement(element)
    ? render(element).container
    : element;

  const results = await axe(container, axeOptions);

  expect(results).toHaveNoViolations();
};

  // And now can use it to test your component in jest like:
  it('should have no basic a11y issues', async () => {
    await testA11y(<YourReactComponent />);
  });

References: jest-axe.

Use CSS to highlight the accessibility issues

For example, you can create a CSS selector to draw attention towards the issues. For example, draw a red outline if an image is missing an alt tag.
And if a developer misses a rule, it would be clearly visible. Check the following examples:


  /* All img tag must have alt attribute. For decorative images, provide empty value (alt="") */
  img:not([alt]) {
    outline: 2px dotted red;
    error: All img elements should have alt attribute;
  }

  /* For tabpanl UI, the <ul> element should have the role of "tablist" */
  .tab ul:not([role="tablist"]) { outline: 0.5em solid red; }

  /* A elements that don't have a class get default styles */
  a:not([class]) {
   text-decoration-skip-ink: auto;
  }

Using Icon only as button

As Icon button has no visible text associated; it's important to make sure the assistive technologies has a way to announce its name.
There are multiple ways to do so. let's one example as suggested by Sara Soudein


 <!-- Using visually hidden text, accessible to screen reader -->
  <button> 
   <svg aria-hidden="true" focusable="false" ...>
        <!-- svg content -->
    </svg>
   <span class="sr-only">Menu</span>
  </button>

and the 'sr-only' would be:

  .sr-only:not(:focus):not(:active) {
   clip: rect(0 0 0 0); 
   clip-path: inset(100%); 
   height: 1px; 
   overflow: hidden; 
   position: absolute; 
   white-space: nowrap; 
   width: 1px; 
 }

You can explore other techniques in this great article referenced below:

References: Accessible Icon Buttons

VisuallyHidden React component

You can easily create a reusable react component using the aforementioned sr-only css. It can also be a part of your component library.

 /**
 * This component will visually hide the content in the DOM, keeping it accessible
 * for the screen reader user.
 */
 import srOnly from '';
 const VisuallyHidden = ({ as: Component = 'span', children }) => (
   <Component className={srOnly}>{children}</Component>
 );

 // And then you can use it like: 
 <VisuallyHidden as="h1">I am visually hidden h1 tag</VisuallyHidden>

Color contrast

It's important to make sure that your UI has a minimum contrast ratio as described in WCAG guidelines.
Not meeting the color contrast ratio can cause users to perceive your text incorrectly.
If you are a developer, you can collaborate in the design process, and enforce this constraint before working on implementing the actual UI.
- References:
- Color contrast WebAim
- WCAG color contrast guidelines
- Accessible colors checker

Accessibility checklist

The following checklists can come in handy when you visually want to keep track of accessibility standards in your app:
- accessibility checklist from a11yproject team can be handy when it comes to keeping things in check.
- accessibility checklist from a11yEngineer

Learn to operate VoiceOver on your Mac

Learning Mac's VoiceOver tool is super easy. A few shortcuts and you shall be able to operate it in no time.
Try using VoiceOver along with a keyboard to browse your website. You will be amazed to see how good or bad your accessibility ranking it.

Use a11y eslint plugin as your dev dependency

Nothing is better than having a development tool that could warn you when your UI has some basic a11y issues.
If your project uses React, eslint-plugin-jsx-a11y is a must-have dev dependency to help you along.

Use ARIA live regions to announce dynamic changes in the page

Use aria-live to let the screen reader knows about the new content that would appear as of some user actions.
Assistive technologies will announce dynamic changes in the content of a live region.
Example would be an alert/notification that would appear when an action is completed.
This is important to remember when you're creating a SPA (single page application) where content changes without a full page reload.
References:
- ARIA live regions (mdn docs)
- Using aria-live

Zoom up the page to 200% and see if you can still use the website

Many users would zoom up your page to 200% or more, and your app should still be functional.
Content shouldn't overlap and your page should still be usable.
Make sure interactive elements are still functional.
References:
- WCAG Resize Text -- Level AA success criteria requirement.

Chrome/FireFox extensions

The following web extensions can help you identify a few of your web accessibility issues right from your browser:

Read articles on accessibility, follow blogs/newsletters

The main issue behind so many inaccessible web apps is the lack of knowledge and awareness about the accessibility guidelines.
You can invest some time learning about these standards and then sharing these with your teammates. You need to take the first step.
I would recommend the following resources if you want to level your accessibility knowledge:

It's not only about the UI

It's not just the UI elements or usage of assistive technologies that correspond to accessibility, it's also about your other web core vitals:

Run lighthouse check and see how well your app is performing overall.
Use code-splitting and lazy loading where possible to avoid sending unnecessary JavaScript.
Don't make too many requests on your first page load.
Think about progressive enhancement and server-side rendering.

Conclusion

Starting a web developer career has become more of knowing about React, VueJS, and AngularJS. The advent of these frameworks has made creating a complex UI so easy that we've forgotten about accessibility guidelines. No doubt our developer experience has improved, but we have paid the cost of forgetting about vanilla JavaScript fundamentals, HTML native elements, and accessibility.

It's the time we resurrect these existing standards and lay down our app using the principles that would make it inclusive and accessible. Accessibility is not optional, and as a developer, it's our sole responsibility to make sure it won't go unattended.

Lazy-loading React components—no rocket science

Amandeep Singh — Sun, 30 May 2021 13:24:20 +0000

Imagine you've been to a café and order a cup of coffee ☕. Once the bill 🧾 arrives, it isn't only for the coffee you ordered, but all the menu items available in the café. How would you feel? Shocking right!! It would be unfair to pay for all the items you haven't even ordered. Without arguing, you paid the bill, and never returned to this café.

Well, that was just an analogy. Let's relate it with our web platform, build with an enormous JavaScript bundle.

Here, our user is the customer, and we(developers) are the café owners. If our user has only requested the registration/signup form, would you also send down the rest of the JavaScript bundle(the bill) responsible for the rest of the pages, carrying huge map or date libraries? How would your user feel? Most likely upset or might not come to your website again, right?

The obvious reason is that their first-page load experience would be slow, and the page might take more time to be interactive (TTI & FID). The browser will keep itself busy parsing the JavaScript, while our users stare at a blank screen with a sad face ☹️.

And the sad thing is that our poor user has no clue that it was us, the developers, who could have been more responsible while sending the full JavaScript bundle down to them in one go.

Welcome to the world of code-splitting where you can lazy-load (dynamically) your JavaScript bundle dynamically, only when the user requested it. The bill you hand over to your user is exactly what they have eaten 😄.

Route-based splitting

All modern JavaScript bundlers, like Webpack. Rollup, and parcel, supports code-splitting feature out of the box. These bundlers can create multiple bundles that can be dynamically loaded at run time, thus improving the web performance for your users.

Splitting your JavaScript bundle based on the routes/pages in your app is called route-based code splitting. For example, if you have login and a home page, you would more likely be splitting the bundle based on these routes. And only send login page JavaScript when the page loads.

NextJS provides this route-based splitting feature out of the box. And if you're using React Router, React-lazy is your best bet.

Component-based splitting

With route-based splitting, we've made our users happy. It's time we take an extra step and implement component-based splitting. Let's understand this with an example, followed by a coding exercise to strengthen our concepts. Before you realize it, it will become a piece of cake for you 🍰.

Imagine you're building a page to show a rental property. There's a button on this page that opens up a full-page map to show its address. This map component carries a complex functionality and has contributed to a large amount of JavaScript bundle.



 import JSHeavyMapComponent from './js-heavy-map-component';

 // Property page component
 export default function Property() {

   const [showMap, setShowMap] = useState(false);

   return <>
      <h1>Rental Property</h1>
      <article>
        <h2>Property description</h2>

        { showMap && <JSHeavyMapComponent /> }

        <button onClick={() => setShowMap(true)}>
          Show map
        </button>
      </article>
   </>
 }

Would you make this map component part of your initial property page (route-based) bundle? What if the user never clicks the button, and only views the property metadata? Wouldn't that be a waste of resources to parse all that extra JavaScript causing the slow page load time?

Yes, it would be unnecessary to send along all this heavy JavaScript bundle in this case. It might cause a heavy toll on mobile users where resources are limited compared to Desktop users.

This is where the component-based loading comes into the picture and mitigates these issues. With this approach, you can lazy-load the map component, and dynamically serve it when the user actually asks for it (click the button). This will make your property page lean, improving the overall page-load performance. You can put more effort, and download the component when the user is about to hover the button, saving you an extra microsecond there.

With the theory aside, we'll see how could you easily implement it in code using the dynamic import feature. We'll see two examples starting with React.lazy approach, and then approach to do the same in NextJS projects using dynamic import feature.

So, let's get started.

Lazy-loading via React.lazy

We need to use React.lazy along with Suspense to lazy-load our Map component dynamically.



// Change the old import to use React.lazy
const JSHeavyMapComponent = React.lazy(() =>
  import("./js-heavy-map-component")
);

// Property page component
export default function Property() {
  const [showMap, setShowMap] = useState(false);

  return (
    <>
      <h1>Rental Property</h1>
      <article>
        <h2>Property description</h2>

        {/* Wrap you dynamic component with Suspense */}
        {showMap && (
          <React.Suspense fallback={<p>Loading...</p>}>
            <JSHeavyMapComponent />
          </React.Suspense>
        )}
        <button onClick={() => setShowMap(true)}>Show map</button>
      </article>
    </>
  );
}

So, with this change, when your property page loads, the browser will not load extra JavaScript for the map component. The loading will only happen when the user hits the Show map button—great saving with just a couple of lines. Didn't I say that it would your piece of cake 😉? Here's the codesandbox demo. Download and run the app locally on your computer. Keep an eye on your network tab when you hit the Show map button. Here's your lazy-loading in action.

Lazy-loading in NextJS

With NextJS, implementing the dynamic loading is as easy as ABC. Similar to React.lazy API, NextJS has an equivalent dynamic module, which also let you pass additional options for loading component.



import dynamic from "next/dynamic";

// Change the old import to use NextJS dynamic import
const JSHeavyMapComponent = dynamic(() => import("./js-heavy-map-component"));

// Property page component
export default function Property() {
  const [showMap, setShowMap] = useState(false);

  return (
    <>
      <h1>Rental Property</h1>
      <article>
        <h2>Property description</h2>

        {showMap && <JSHeavyMapComponent />}
        <button onClick={() => setShowMap(true)}>Show map</button>
      </article>
    </>
  );
}

And here's the codesandbox demo for it if you want to play along.

Conclusion

My main goal through this article was not only to tell you how to implement the code-splitting (the official docs are great resources for this) but to help you think about why do we need it in the first place. Remember that your beautiful app is of no good use if it takes minutes to load. User is the focus, and we should be mindful of what we send across the wire to the clients. Don't make your users pay the cost for the additional JavaScript. And with such a great set of tooling at our disposal, there's no excuse to not do code-splitting. Your uses will thank you for this.

Think inclusive, think accessible.

Curated list of Newsletters to level up your coding skills

Amandeep Singh — Sun, 16 May 2021 04:34:04 +0000

Taking one step forward

Learning is an unending process. The era we live in carries a plethora of resources to grab those learning opportunities—a major one is the 'Internet'.

If you're working for a company, you might be learning from your peers, seniors, & colleagues. This is important to hone your skills, especially in software engineering where things are evolving every day. And as the metaphor goes, Standing on the shoulders of giants, is completely true, and so does this quote, "If you don't step forward, you're always in the same place".

So, let's take one step forward, and I'd like to share a list of newsletters, which I have had been reading for a while. These newsletters are mostly focused on front-end (JavaScript, CSS, HTML, and Accessibility) topics but also cover UX, Usability, and Design.

Overall great freebie packages, written by industry professionals, which get delivered to you while you sleep in the night 🛌. Let's get started.

1. CSS, HTML

CSS Layout
- about: tutorials, news, information on all things CSS Layout
- frequency: weekly
- by: Rachel Andrew
CSS Weekly
- about: CSS articles, tutorials, experiments, and tools
- by: Zoran jambor
CSS-Tricks
- about: focussed on CSS, but covers other web dev topics too
- frequency: weekly
- by: Chris and CSS-Tricks team
Modern CSS
- about: CSS tips, accessibility, updates & front-end resources
- by: Stephanie Eckles
Smashing Magazine
- about: Front-End, UX
- frequency: weekly
- by: Smashing Magazine

2. JavaScript

bytes by U;
- about: JavaScript ecosystem
- frequency: every Monday
- by: Tyler McGinnis
ES.next
- about: the latest in JavaScript and cross-platform tools
- frequency: weekly
- by: Dr. Axel Rauschmayer and Johannes Weber
JavaScript Weekly
- about: JavaScript articles, news and cool projects
- by: Cooper Press
Go Make things
- about: short email focussed on vanilla JavaScript, code snippets, tools, techniques
- frequency: each weekday
- by: Chris Ferdinandi

3. Accessibility, UX, Design

A11y Weekly
- about: web accessibility
- by: David A. Kennedy
Good Design
- about: Design, UI, and UX
- frequency: monthly
- by: Adam Silver
UX Collective
- about: UX, Design
- frequency: weekly
- by: Fabricio Teixeira
Neilsen Norman Group
- about: Design, Usability, and UX research
- frequency: weekly
- by: Nielsen Norman Group

4. ReactJS

React Newsletter
- about: React news, tutorials, resources
- frequency: every Tuesday
- by: Tyler McGinnis
Kentcdodds newsletter
- about: tutorials and articles on React, JavaScript and Node
- by: Kentcdodds

5. NodeJS

Node Weekly
- about: Node.js news and article
- by: Cooper Press

6. GraphQL

GraphQL Weekly
- about: news, articles and projects about GraphQL
- by: Prisma, Novvum

7. Web Dev & Tips

Stefan's web weekly
- about: web dev learnings, productivity tips, useful GitHub projects, devsheets, & music
- by: Stefan Judis
FrontEnd Focus
- about: front-end news, articles and tutorials. HTML, CSS, WebGL, Canvas, browser tech, and more
- frequency: weekly
- by: Cooper Press

8. Career Growth

Human Who Codes
- about: intended for web application engineers who want to grow their career; covers JS, web dev, leadership, architecture, teamwork
- frequency: every other Tuesday of the month
- by: Nicholas C.Zakas

Conclusion

Subscribing to these newsletters is half the battle won. You need to schedule a plan to read them on regular basis, otherwise, these emails may start to feel overwhelming. In your inbox, you can also filter and label them accordingly based on the category I showed you above. And then pick one or two specific topics to read on a regular interval. It's about putting in small efforts and being consistent.

If you work for a company, you can share these new updates in a brown bag, or knowledge-sharing sessions. Soon you'll realise how far have you come.

Thanks for reading, and do share this list with others so that they can join you on riding the giants. Good luck 🙂.

Are you sure you know how an event propagates in JavaScript?

Amandeep Singh — Wed, 17 Feb 2021 13:33:38 +0000

Events are everywhere in web programming — input change, mouse move, button click, and page scroll are all forms of events. These are the actions that get generated by the system so that you can respond to them however you like by registering event listeners.
This results in an interactive experience for the user. Understanding how the event model works in modern web browsers can help you build robust UI interactions. Get it wrong, and you have bugs crawling around.

My aim through this article is to elaborate some basics around the event propagation mechanism in the W3C event model. This model is implemented by all modern browsers.

Let's get started ⏰.

Event propagation

Imagine If we have two HTML elements, element1 and element2, where element2 is the child of element1 as shown in the figure below:

And we add click handlers to both of them like this:

element1.addEventListener('click', () => console.log('element1 is clicked'));
element2.addEventListener('click', () => console.log('element2 is clicked'));

What do you think will be the output when you click element2? 🤔

The answer is element2 is clicked, followed by element1 is clicked. This phenomenon is known as Event bubbling, and it's a core part of the W3C event model.

In event bubbling the innermost target element handles the event first, and then it bubbles up in the DOM tree looking for other ancestor elements with registered event handlers.

💡 In event bubbling the innermost target element handles the event first and then it bubbles up in the DOM tree

Now, the interesting bit is that event flow is not uni-directional, as you might have assumed. The event flow mechanism in the W3C event model is Bi-directional. Surprise Surprise! 😯.

We mostly have been dealing with event bubbling when working with frameworks like React and never think much of another phase which is Event Capturing.

💡 Event bubbling is just one side of the coin; Event capturing is the other.

In the event capturing phase, the event is first captured until it reaches the target element (event.target). And you, as a web developer, can register your event handler in this phase by setting true as the third argument inside the addEventListener method.

// With addEventListener() method, you can specify the event phase by using `useCapture` parameter.
addEventListener(event, handler, useCapture);

By default, it's false indicating that we are registering this event in the bubbling phase.
Let's modify our example above to understand this better.

// Setting "true" as the last argument to `addEventListener` will register the event handler in the capturing phase.
element1.addEventListener('click', () => console.log('element1 is clicked'), true);

// Whereas, omitting or setting "false" would register the event handler in the bubbing phase. 
element2.addEventListener('click', () => console.log('element2 is clicked')));

We have added true for useCapture parameter indicating that we are registering our event handler for element1 in the capturing phase. For element2, omitting or passing false will register the event handler in the bubbling phase.

Now, if you click element2, you will see element1 is clicked is printed first followed by element2 is clicked. This is the capturing phase in action.

💡 In the event capturing phase, the event is first captured until it reaches the target element

Here's the diagram to help you visualise this easily:

The event flow sequence is:

The "click" event starts in capturing phase. It looks if any ancestor element of element2 has onClick event handler for the capturing phase.
The event finds element1, and invokes the handler, printing out element1 is clicked.
The event flows down to the target element itself(element2) looking for any other elements on its way. But no more event handlers for the capturing phase are found.
Upon reaching element2, the bubbling phase starts and executes the event handler registered on element2, printing element2 is clicked.
The event travels upward again looking for any ancestor of the target element(element2) which has an event handler for the bubbling phase. This is not the case, so nothing happens.

So, the key point to remember here is that the whole event flow is the combination of the event capturing phase followed by the event bubbling phase. And as an author of the event handler, you can specify which phase you are registering your event handler in. 🧐

With this new knowledge in our bag, it's time to look back to our first example and try to analyse why the output was in reverse order. Here's the first example again so that you're not creating a scroll event 😛

element1.addEventListener('click', () => console.log('element1 is clicked'));
element2.addEventListener('click', () => console.log('element2 is clicked'));

Omitting the useCapture value registered the event handlers in the bubbling phase for both the elements. When you clicked element2, the event flow sequence was like:

The "click" event starts in capturing phase. It looks if any ancestor element of element2 has onClick event handler for capturing phase and doesn't find any.
The event travels down to the target element itself(element2). Upon reaching element2, the bubbling phase starts and executes the event handler registered on element2, printing element2 is clicked.
The event travels upwards again looking for any ancestor of the target element(element2) which has an event handler for the bubbling phase.
This event finds one on element1. The handler is executed and element1 is clicked is printed out.

Another interesting thing you can do is logging out the eventPhase property of the event. This helps you visualise which phase of the event is currently being evaluated.

element1.addEventListener("click", (event) =>
  console.log("element1 is clicked", { eventPhase: event.eventPhase })
);

Here's the codepen demo if you like to play with it. Or you can paste the code snippet below in your browser and see it yourself.

const element1 = document.createElement("div");
const element2 = document.createElement("div");

// element1: Registering event handler for the capturing phase
element1.addEventListener(
  "click",
  () => console.log("element1 is clicked"),
  true
);

// element2: Registering event handler for the bubbling phase
element2.addEventListener("click", () => console.log("element2 is clicked"));

element1.appendChild(element2);

// clicking the element2
element2.click();

Stopping the event propagation

If you wish to prevent further propagation of current event in any phase, you could invoke stopPropagation method available on the Event object.

So, it means invoking the event.stopPropagation() inside the element1 event handler (in capturing phase), would stop the propagation. And if even if you click element2 now, it won't invoke its handler.

The following example demonstrates that:

// Preventing the propagation of the current event inside the handler
element1.addEventListener(
  "click",
  (event) => {
    event.stopPropagation();
    console.log("element1 is clicked");
  },
  true
);
// The event handler for the element2 will not be invoked.
element2.addEventListener('click', () => console.log('element2 is clicked'));

Note that event.stopPropagation stops the propagation only. It does not, however, prevent any default behaviour from occurring. For example, clicking on links are still processed. To stop those behaviours, you can use event.preventDefault() method.

Finally, here's another cool JSbin demo if you like to play along and see how can you stop the event propagation via event.stopPropagation.

I hope this article was helpful and has given you some insights. Thanks for reading 😍

Useful resources:

Introduction to "DOM Events" - (whatwg specs)
Introduction to events - (Mozilla documentation)
Event phases and stop propagation demo - (JSbin demo)

An Easy Explanation to Prototypal Delegation in JavaScript

Amandeep Singh — Sun, 18 Oct 2020 11:14:27 +0000

JavaScript language stands on two pillars: functional programming and prototypal delegation. The addition of classes in JavaScript is mere a syntactic sugar to give it Object-oriented programming feel: unwrap them and you will find functions inside.

Prototypal Delegation

Prototypal delegation is all about delegating the responsibility to the prototype higher up in the [[Prototype]] chain.

function foo(){}

Object.getPrototypeOf(foo) === Function.prototype; // true
Object.getPrototypeOf(Function.prototype) === Object.prototype; // true
Object.getPrototypeOf(Object.prototype); // null

The prototype chain will look like this:

foo --> Function.prototype --> Object.prototype --> null

In simple words, if you try to look for a property that is not owned by the object, the JavaScript engine will traverse up its prototype chain until it finds it. Let's see an example to understand it.

const recipe = { name: "Garlic Naan" };

const recipeBook = {
  getRecipeName() {
    console.log(this.name);
  },
};

// Set 'recipeBook' as the prototype of 'recipe'
Object.setPrototypeOf(recipe, recipeBook);

// Prototypal delegation in action
recipe.getRecipeName(); // prints 'Garlic Naan'

The prototype chain will look like this:

recipe --> recipeBook -> Object.prototype --> null

The object recipe doesn't own the getRecipeName property. But by setting recipeBook as its prototype, we have delegated the job of printing the name to the recipeBook instance. This is called the prototypal delegation.

Now, let say you also want recipe to delegate the task of orderRecipe() to another instance order. You can do this by extending the prototype chain like:

const order = {
  orderRecipe() {
    console.log(`${this.name} ordered!`);
  },
};

// Extending the prototype chain
Object.setPrototypeOf(recipeBook, order);

recipe.orderRecipe(); // prints 'Garlic Naan ordered!'

The prototype chain will extend to this:

recipe --> recipeBook --> order --> Object.prototype --> null

Now, I think it should be easy to relate why you are able to invoke recipe.hasOwnProperty() even though none of the object literals we declared owned hasOwnProperty. This is because all object literals implicitly inherit from Object.prototype, which means the hasOwnProptery() task has been delegated to Object.protoype.

Here's the complete code example:

const recipe = { name: "Garlic Naan" };
const recipeBook = {
  getRecipeName() {
    console.log(this.name);
  },
};

// Set 'recipeBook' as the prototype of 'recipe'
Object.setPrototypeOf(recipe, recipeBook);

const order = {
  orderRecipe() {
    console.log(`${this.name} ordered!`);
  },
};

// Extending the prototype chain
Object.setPrototypeOf(recipeBook, order);

// Prototypal delegation in action
recipe.getRecipeName(); // prints 'Garlic Naan'
recipe.orderRecipe(); // prints 'Garlic Naan ordered!'
recipe.hasOwnProperty("name"); //true

Constructor function and the new keyword

Before I leave you with this delegation concept, I also want to talk about constructor functions and why do you need to use the new operator when creating instances. I hope with the prototype concept aside it should be easy to demystify their existence.

Every function (except fat arrow) in JavaScript has a property called prototype which is just a plain object with constructor property. This is different from the internal [[Prototype]] relationship.

Let's revisit the previous recipe example and see how can you establish the same prototypal relationship using the constructor function.

// Constructor function 'Recipe'
function Recipe(name) {
  this.name;
}

Recipe.hasOwnProperty("prototype"); // true
Recipe.prototype.constructor === Recipe; // true

Visually it will look similar to the diagram below:

The property (prototype) is special because when you invoke Recipe() using the new operator, the new operator uses Recipe.prototype as a prototype for instances it creates. Once the instance is created, the new operator passes that instance as this internally as one of the parameters to Recipe().

const recipe = new Recipe('Garlic Naan');

Now, it should be clear that why do we need to add properties to Recipe.prototype: they become available on all the Recipe instances via prototypal delegation.

__proto__ is a pseudo property for accessing the prototype of an object

// Adding properties to 'Recipe.prototype' will make them 
// available on all `Recipe` instances. 
Recipe.prototype.getRecipeName = function () {
  console.log(this.name);
};

Similarly, we can extend the chain and delegate the task of ordering the recipe to another object by setting it as a Recipe.prototype prototype.

// Order constructor
function Order() {}

Order.prototype.recipeOrder = {
  recipeOrder() {
    console.log(`${this.name} ordered!`);
  },
};

// Setting up the delegation aka Prototypal inheritance
Object.setPrototypeOf(Recipe.prototype, Order.prototype);

recipe.orderRecipe(); // prints 'Garlic Naan ordered!'

The complete code example using Function constructor looks like:

// Constructor function 'Recipe'
function Recipe(name){this.name}

Recipe.hasOwnProperty('prototype'); // true
Recipe.prototype.constructor === Recipe; // true

const recipe = new Recipe('Garlic Naan');

Recipe.prototype.getName = function () {
  console.log(this.name);
};

// Order constructor
function Order() {}

Order.prototype.recipeOrder = {
  recipeOrder() {
    console.log(`${this.name} ordered!`);
  },
};

// Setting up the delegation aka Prototypal inheritance
Object.setPrototypeOf(Recipe.prototype, Order.prototype);

// Prototypal delegation in action
recipe.getRecipeName(); // prints 'Garlic Naan'
recipe.orderRecipe(); // prints 'Garlic Naan ordered!'
recipe.hasOwnProperty("name"); //true

Here's how the final prototype chain looks like:

Closing thoughts

Prototypes in JavaScript may seem daunting to begin with, but I hope this article has eased your learning path. Understanding the foundation of JavaScript is the key to become a good developer. If you want to explore more about the prototype chain, then I highly recommend reading this chapter by Dr. Axel. Thank you for reading 😍.

How to smartly cleanup your commit history using git reset?

Amandeep Singh — Sun, 16 Aug 2020 16:37:54 +0000

TLDR

Running git reset --soft <commit-hash> will move the branch to this old commit. And now when you run git status, you will see all the changes you have made since commit-hash in your staging area. You can then create a single commit to update your commit history.

With --mixed(also a default) flag, Git will match your staging area with the content snapshot at that commit, which means all those changes since old commit have been unstaged too. Now, you can selectively stage those files and can create multiple new commits however you want.

A commit message should justify your intent for the change, and not just add unnecessary noise to the Git history. Therefore, It's a good habit to keep your commit history clean and Git has a few tools to achieve this.

In this article, I will show you how you can smartly clean up your commit history using git reset But before I throw in that tip, I would also like to unveil the reasoning behind it so that it can be more fruitful in a long run.

If you wish to skip the basics, you can jump straight to the cleanup section too.

Let's get started.

Pointers 👈

HEAD and branch are two different concepts in Git. The branch is just a lightweight movable pointer to one of the commits you are on, whereas, HEAD by default points to the branch you are currently on.

When Git moves the HEAD, it also modifies the index and working directory to reflect the changes of that commit.

Now when you run git reset, it moves the branch HEAD is pointing to. For example, if you are on master branch, running git reset 8fgh5 will move the branch to this commit as shown in the picture below:

💡 git reset moves the branch HEAD is pointing to; git checkout <branch-name> moves the HEAD to that branch.

Git reset has 3 flavours at your disposal: --soft, --mixed, and --hard. Irrespective of which one you chose, running git reset will always start by moving the branch HEAD points to, and stops where you ask it to. It runs the following operations in order:

Move the branch HEAD point to (stop here if --soft).
Modify the index(staging area) to look like HEAD (stop here if --mixed).
Make the working directory looks like the index (--hard).

With the foundation set aside, let's see how can you use the --soft and --mixed(also a default) options with git reset to clean up your commit history.

Time for some awesomeness 🎉.

It's cleanup time ⏰

If you have been lazily writing multiple vague commits, you can use git reset --soft <old-commit> to make your branch point to that old commit. And as we learned, Git will start by moving the branch pointer to it and stops right there. It won't modify the index or working directory. And everything you have committed so far since this commit (old-commit) will be shown in your staging area. It essentially undid all the git commit commands. Running git status will now show 'Changes to be committed' message.

Now, you can go ahead and commit those changes with a new message 😍.

I normally use --soft reset variant when I feel like squashing old commits into a single commit. But if you wish to create multiple commits starting from old-commit, you can also run git reset <old-commit>. Git runs this command with --mixed option by default. Doing so, Git will move your branch to that commit but also modifies your index area to match HEAD. In other words, all the changes you have committed since then will be unstaged. Think of it as the opposite of git add. Running git status will now show Changes not staged for commit message.

Now you can selectively add files to the staging area and create meaningful commits to clean up your commit history.

💡 HEAD~{n} refers to the nth parent of your HEAD. So, HEAD~1 gives you the first parent commit of HEAD.

Closing thoughts 👋

I've always enjoyed this proverb:

"Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime."

I hope that through this article I have not just given you a tip, but also have elaborated the rationale behind it. Now you can feel more confident using git reset in your daily workflow. Strive to keep your commit history clean, and your future colleagues will thank you for this 🙏.

That's for today. And if you are interested in learning another tip, here's my article about git interactive.

Git Interactive—enhance your work productivity 10X

Amandeep Singh — Fri, 31 Jul 2020 17:28:41 +0000

Git has a plethora of commands at your disposal. But we often end up using only a handful of those in our daily git workflow. The git add and git checkout are one of those indispensable commands:

git add .  // stage the modified content of the working directory
git checkout <branch-name> // for checking out to other branches

But, I have often seen devs not leveraging these commands to their full power. The aforementioned usages are often enough to get the job done. Moreover, our mind is so comfortable in using them that we don’t want to explore what rest they have to offer.

This article is my attempt to change how you think about these two commands. Welcome to the world of git interactive.

1. Interactive Staging

git add -p

Explanation

This command gives you the flexibility of selecting granular changes, and mark them accordingly to go into your staging area. Instead of adding a complete file, You can stage only desired hunks of diffs from it and leave the rest. For e.g, If you have made two changes in your tracked file README.md , you can stage one of them and not the other.

Use Cases

Add smaller commits

We should strive to keep our commits smaller. A commit subject should be enough to justify your reason for the specified change.

In those scenarios, where you have gone too far and refactored a huge bunch of code, git add -p is your best bet. It helps you to add small and isolated changes and make them ready for a commit. You can re-visit and select more hunks to be part of the subsequent commits.

Handy while debugging and refactoring

While diagnosing an issue, you might have sprinkled a whole bunch of console.log statements. Doing so, you might have refactored a few lines of code that you might want to keep for future commits.

You can smartly use git add -p to cherry-pick those useful lines of code and create a commit out of that. This will leave the log statements in your working directory, which you can safely discard later on.

2. Interactive checkout

git checkout -p

Explanation

This command allows you to discard hunks interactively from your working directory. In other words, it does the opposite of interactive staging. Instead of discarding all the changes in a file, you can choose which part of the file you want to remove and keep the rest 🚀.

Use Cases

Keeping your working directory clean

If you have been brainstorming about an idea, and have quickly scribbled a few lines to code. You can invoke this command and interactivity remove irrelevant code from your working directory, leaving important bits to become part of the staging area.

Handy while debugging

The same use case as we have for interactive staging, but works in reverse order. Instead of cherry-picking useful bits, you can discard the unnecessary log statements and leave the important work for future staging.

This is all for now. To learn more about git tools and command, I highly recommend reading this book here.  Now go ahead and give these commands a try. Let me know your thoughts in the comments below.

Also, if you've enjoyed reading this article, please don’t forget to show some ❤️.

What’s the deal with Object.prototype.hasOwnProperty.call()?

Amandeep Singh — Fri, 24 Apr 2020 16:37:13 +0000

I am sure you might have seen the following line of code either while reading someone’s code or in a library.

Object.prototype.hasOwnProperty.call(objRef, 'propName');

And now you are wondering what on earth this code is doing. You start doubting your JavaScript skills. Don’t worry. You are at the right place.

I have chosen this piece of code for a few purposes, and by demystifying this, we will understand the following things:

What is Object.prototype?
How an object can borrow a function without implementing it or having it in its prototype chain?
Why do we access hasOwnProperty on the Object's prototype and not on the instance itself?

If this sounds intriguing to you, let’s get started.

1. Object.prototype

Prototypal inheritance is one of the main pillars of JavaScript language which allows an object to inherit methods and properties on its prototype. You can think of the prototype as a template.

Prototypal inheritance allows an object to inherit methods and properties on its prototype.

It’s better to understand with an example:

var obj = {name: 'aman'}
obj.hasOwnProperty(‘name’)  // returns true

As you see, we haven’t defined any hasOwnProperty on our obj object but we managed to invoke it. How is it possible? 🤔

This is possible due to the prototypal inheritance and the way prototype chain works. Let’s dig a bit deeper.

When we created our literal object obj, its prototype was set to Object.prototype. To verify we can see:

Object.getPrototypeof(obj) === Object.prototype // returns true

[[Prototype]] is an inheritance relationship between objects. In our case, it’s the relation between the obj and Object’s prototype.

The prototype chain looks like:

// Prototype chain
obj —-> Object.prototype ——> null

When we try to access a property on an object, the interpreter first looks for it on the object itself. If it couldn’t find the property on the object, it will traverse up until it finds the property in the chain.

Thus, when we invoked hasOwnProperty(), the interpreter couldn't find it on the obj, so it traverses up in the chain and finds it on Object.prototype.

Additionally, We can set up or override the prototype chain however we want by using Object.setPrototypeOf() method or by using Object.create().

Consider this example:

var person = {name: 'peter'};
var PersonPrototype = {getName: function(){ return this.name; }}; 

// Setting person's prototype 
Object.setPrototypeOf(person, PersonPrototype);

// Trying to access getName() method will cause a prototype chain lookup (aka prototype delegation) 
// and finds it on PersonPrototype. 
person.getName(); // 'peter'

2. Borrowing a function

Let's imagine If I have a following function and an object:

function sayHello() { console.log(`Greetings ${this.name}`) }
var a = {name: 'peter'};

How would you make the object a borrow sayHello, and invoke the correct name in the greetings? We don't want a to implement sayHello or have it anywhere on its prototype chain. 🤔

The answer is via call and apply method available on Function.prototype.

In JavaScript, every function we create inherits from Function.prototype.
And as we have just learned that via prototype chain, we can use call method on all function objects. 💡

In JavaScript, every function we create inherits from Function.prototype.

The syntax of call method is:

// 'call' method is available on Function.prototype
func.call(objRef, ...args);

The first argument is an object who wants to borrow this function followed by the list of arguments for that function.

So, for a to borrow sayHello, all we have to do is use call method on sayHello passing a as an argument:

sayHello.call(a); // Greetings peter

3. Object.prototype.hasOwnProperty vs instance.hasOwnProperty

After a lightweight tutorial on Prototypal inheritance and borrowing functions, finally, it's time to demystify why one would use hasOwnProperty on the Object.prototype and not on the object instance.

As we mentioned above that we can control the prototype chain ourselves. One way is to use Object.create() method while creating Object instance.

// Object.create() accepts an argument which becomes
// the prototype for newly created object.
var a = Object.create(null); // Setting `null` as prototype for 'a'. 

// Adding a 'name' property on the instance
a.name = 'peter';

// Using `hasOwnProperty` method would cause an error
a.hasOwnProperty('name'); //🚫 throws a TypeError: a.hasOwnProperty is not a function

Trying to invoke hasOwnProperty throws an error as there's no such method available on the object or its prototype chain. The prototype chain was like:

// Prototype chain
a ---> null

You may be wondering why someone would create an object like this. But the irony is that in JavaScript you are allowed to be as crazy as you want 🔥.

Imagine you are creating a library and exposing a function that accepts an object as an argument. If your function makes use of hasOwnProperty directly on the object being passed from outside, it could break your code if someone passes an object with null as its prototype.

Consequently, to guard this problem we can use function borrowing technique we previously learned. The passed-in object argument can borrow hasOwnProperty available on Object.prototype as we previously learned via call method. 🚀😇.

// Will not break your code if 'a' has a null prototype. ✅
Object.prototype.hasOwnProperty.call(a, 'name'); // true;

Summary

Every object literal inherits from Object.prototype. This allows you to invoke some of the methods available like hasOwnProperty.
We can override/create the prototype chain with the help of Object.setPrototypeOf method and via Object.create(prototype).
Every function inherits from Function.prototype allowing you to consume methods like call, apply, and bind.
An object can borrow other functions without implementing them or having them in their prototype chain. This can be achieved by using call or apply method available on Function.prototype.
Use Object.prototype.hasOwnProperty.call(objRef, 'propName') to guard the TypeError when objRef has null prototype.

That's all for now. I hope you have enjoyed reading this article and learned a few things. Go and share this achievement with others 😍.

Abstract Operations—the key to understand Coercion in JavaScript

Amandeep Singh — Tue, 27 Aug 2019 14:02:40 +0000

I was intrigued by one the question asked on my So you think you know JavaScript article.

 {} + []; // returns 0 ?? 🤔

I admit that I didn't know the correct answer at that moment, but instead of blaming and criticising the JavaScript coercion and type system, I delved into the specs to find the definition of Addition operator. At first, the specs didn’t make much sense to me. I found it verbose. May be my brain wasn't trained on reading the specs. Yeah, let's be honest, how many of us read the specs when there's a question about JavaScript? We have our beloved StackOverflow. Right?

Well, I was desperate to know the answer. I didn't want to be in the category of those devs who consider coercion as some internal magic and dangerous, to be shunned or avoided.

So, this article is to share my understanding of coercion in JavaScript, and illustrate why coercion's bad reputation is exaggerated and somewhat undeserved—to flip your perspective so you can see its usefulness and power.

JavaScript Type System

JavaScript is a dynamically typed language where variables don't have types—values have types. JavaScript type system doesn't enforce that the variable always holds the same initial type it starts out with.

  // variable 'a' starts out with holding a string value type. 
  var a = 'some string'; 

  // you can change the type in the next line and it's completely valid
  // Now, the variable 'a' holds the value of type number
  a = 10;

I always see this as one of the strongest points of the JavaScript type system. But some devs from strongly typed language may find this as a flaw in the language and object the usage of word 'type'. And I think that's one of the many reasons we are perpetually exploring the ways (Flow and TypeScript) to put a layer of type system on the language. In my opinion, it's like we are duck-taping JavaScript into a system which is not in the DNA of the language.

I believe we should always strive to learn the fundamentals and think alike JavaScript. Instead of flowing against it, let's flow towards it and see why the aforementioned question shouldn't be overhyped thinking that JavaScript is weird.

Let's quickly revisit what we know so far about JavaScript types and then we will deep dive into coercion in the later sections.

JavaScript has seven built-in types:

null
undefined.
string
number
boolean
object
symbol

Except object, all other types are called 'Primitives'. typeof operator is a nice built-in utility to check the types. Keep in mind that typeof always returns a string type.

typeof 'you are awesome!' // 'string'
typeof 42                 // 'number'
typeof true               // 'boolean'
typeof undefined          // 'undefined'
typeof {name: 'aman'}.    // 'object'
typeof Symbol()           // 'symbol'

------------------------
typeof function foo(){}.  // 'function'
typeof []                 // 'object'

You will be wondering why invoking typeof on function and array return 'function' and 'object' respectively. The reason is that functions and array are subtypes of the object type. And because of this, you are able to add properties to the function and invoke some of the methods which an object type has—toString(), and valueOf().

function foo(a,b){}

// you can add any property on foo object. 
foo.someProperty = 'I am a property on foo function'; 

// function object has 'length' property set to number of formal params it takes when declared
foo.length; // 2

// invoke 'toString()' 
foo.toString(); // "function foo(a,b){}"

// invoke 'valueOf'
foo.valueOf(); // return this -> the function itself

Bonus: According to the typeof spec, if an object type implements an internal [[Call]] method, then typeof check returns "function". Object literals and array don't implement it, but the function does.

There are a few gotchas you need to be aware of with typeof operator. As you may have noticed that I have excluded typeof null from the list above. The reason is that null is a special case where typeof operator returns 'object'. It's the only primitive in JavaScript which is 'falsy' and returns 'object' from typeof check.

Note: null is the only primitive in JavaScript which is 'falsy' and returns an ’object' from typeof check.

typeof null; // 'object';

So, how would you go about checking the null type explicitly? You may need a statement like:

var a = null; 
!a && typeof a == 'object'; // true

// Or you can use strict equality comparison
a === null; // true

Let's consider one more quirk with typeof operator:

var a; 
typeof a; // 'undefined'
typeof b; // 'undefined'

In JavaScript, var declared variables get assigned a value of undefined when they have no current value. And that's the reason typeof operator returns 'undefined'. But if you see we haven't declared the variable b anywhere, but typeof operator still manages to print 'undefined'. It's because JavaScript engine is playing safe and instead of returning some error, it returns undefined.

As I said knowing these difference is like aligning your mind with JavaScript engine. Every language has some corner cases. JavaScript is not an exception. Instead of making a joke about the language, I think it's crucial to understand them so that you can take better decisions in your program.

Now, let's move on to the next part of understanding coercion in JavaScript.

Coercion

Coercion aka 'type conversion' is a mechanism of converting one type to another. In statically (strongly) typed language this process happens at compile time whereas coercion is a run-time conversion for dynamically typed languages.

In JavaScript, we can have two types of coercion: "implicit" and "explicit". As the name implies, implicit coercion is the one which happens as a less obvious side effect of some intentional operation. On the contrary, the explicit conversion is obvious from the code that it is occurring intentionally.

var a = 10; 

var b = 'programmer' + a;           // implicit coercion
var c = `you owe me ${a} dollars`.  // implicit coercion

var d = String(a);                  // explicit coercion
var e = Number('42')                // explicit coercion

Have you ever wonder how coercion works internally? That's where things get interesting. But before we can explore the internal procedures, we need to understand some of the operations which are defined in ECMAScript 2020 section 7 called Abstract operation. These operations are not part of the language but are used to aid the specification of the semantics of JavaScript language. You can think of these operations as conceptual operations.

Abstract Operations

Every time a value conversion happens, it is handled by one or more abstract operation with some rules defined in the spec. Here we will look into three abstract operations: ToString, ToNumber and ToPrimitive.

Abstract operations are used to aid the specification of the semantics of JavaScript language.

ToString

Whenever we coerce a non-string value to a string value, ToString handles the conversion as in section 7.1.12 of the specification. Primitive types have natural stringification. The table looks like:

// ToString abstract operation (string conversion)
null ->            'null'
undefined ->       'undefined'
true ->            'true'
false ->           'false'
52 ->              '52'

For regular object and array, the default toString() is invoked which is defined on the Object.prototype

var a = {language: 'JavaScript'}; 
a.toString(); // "[object Object]"

[].toString(); // ""

You can also specify your own toString method to override the default return value:

var a = { language: 'JavaScript', toString(){return 'I love JavaScript'} }; 

a.toString(); // "I love JavaScript"

ToNumber

Whenever a non-number value is supplied in an operation where a number was expected, such as a mathematical operation, ES2020 defines a ToNumber abstract operation in section 7.1.3. For example

// ToNumber abstract operation (number conversion)
true ->           1
false ->          0
undefined ->      NaN (not a valid number)
null ->           0

For object and array, values are first converted to their primitive value equivalent (via ToPrimitive operation) and the resulting value is then coerced into number according to the ToNumber abstract operation.

ToBoolean

ToBoolean is a little simpler than ToString and ToNumber operation as it doesn't do any internal conversion. It only performs a table lookup as mentioned in section 7.1.2.

Argument type	Result
undefined	false
null	false
boolean	return argument
number	if argument is +0, -0 or NaN, return false; otherwise true
string	if argument is empty string, return false; otherwise true
symbol	true
object	true

ToPrimitive

If we have non-primitive type (like function, object, array) and we need a primitive equivalent, ES2020 defines ToPrimitive in section 7.1.1.

ToPrimitve operation takes two arguments: input and hint(optional). If you are performing a numeric operation, the hint will be a 'number' type. And for string operation (like concatenation), the hint passed will be a string. Note that ToPrimitive is a recursive operation which means that if the result of invoking ToPrimitive is not a primitive, it will invoke again until we can get a primitive value or an error in some cases.

Now let's look at the algorithm behind the ToPrimitive operations.

Every non-primitive can have two methods available: toString and valueOf. If 'number' hint is sent, valueOf() method is invoked first. And if we get a primitive type from the result then we are done. But if the result is again a non-primitive, toString() gets invoked. Similarly, in the case of 'string' hint type, the order of these operations is reversed. If the invocation of these two operations doesn't return a primitive, generally it's a TypeError.

Visually, The order can be seen as follows:

// ToPrimitive Abstract Operation

// hint: "number" 
valueOf()
toString()

// hint: "string"
toString()
valueOf()

To make it more clear here's the flow chart diagram of the algorithm we discussed above:

Now armed with this new knowledge of abstract operations, it’s the time to answer a few questions confidently.

Testing our knowledge

// Why the following expression produces '5' as a result? 
[] + 5; // '5'

As per the specification in section, the addition operator ‘+’ performs string concatenation or numeric addition based on the argument type. If either of the argument is string, it will perform string concatenation. It's called operator overloading. Now let see how did we end up getting the string ”5”?

We were expecting a primitive type but end up getting an array as one of the argument. Consequently, ToPrimitive abstract operation is performed with "number" passed as a hint. Referring to the ToPrimitive diagram above, we can assert the following steps will take place to get the result.

[].valueOf() // returns [];
As, [] is not a primitive, engine will invoke [].toString() resulting in an empty string.
Now the expression reduces to "" + 5.
As we mentioned that addition operator performs string concatenation when either of argument is a string type.
So, 5 will be implicitly coerced to “5” via ToString abstract operation passing 'string' as a hint.
Finally the expression reduces to "" + "5" resulting in value "5".

[] + 5;               // ToPrimitive is invoked on []
// "" + 5; 
// "" + "5"; 
// "5"

Now, that's a moment of inner satisfaction. Isn't it? I don't know about you but when I figured this out, I was delighted💡😀.

Before we wrap up, let's quickly demystify some of the following expression to strengthen our grip. I am going to reduce the expression from top to bottom (via abstract operations) to reach the result.

[] + [];            // ToPrimitive is invoked on both operands
// "" + "";
"" 
-----
[] + {};              // ToPrimitive is invoked on both operands
// "" + "[object Object]";
"[object Object]"

-----
'' - true; 
// There's no operator overloading for subtract operator. 
//ToNumber is invoked on both the operands (already primitive)
// 0 - 1; 
-1

------
1 < 2 < 3; 
// (1 < 2) < 3;      
// true < 3;              // ToNumber is invoked on true -> 1
// 1 < 3;
true; 

------
3 < 2 < 1; // true ooops! 
// (3 < 2) < 1; 
// false < 1;             // ToNumber is invoked on false -> 0
// 0 < 1; 
true

Now is the right time to answer the question which basically led me to write this article.

{} + []; // 0 🤔??

Here '{}' is not an empty object but just an empty block {}. So, JavaScript engine ignores it and left with + [] statement to execute. It’s a numeric operation and hence a ‘number’ hint will be passed to convert this empty array into a primitive value, which is an empty string. Finally, the empty string is coerced again via ToNumber operation leading to a value of 0. 😀

{} + [];                 // empty block is ignored
// + [];
// + '';
// + 0 ;
0

Summary:

JavaScript is a dynamically typed language where values have type—not the variables.
Coercion aka “type conversion” is a procedure of converting one value type to another; it happens at compile time for JavaScript.
Coercion can be of two types: implicit and explicit.
Abstract operations are the keys to understanding coercion. They are not actual operation in the language but are used to aid the specification of the semantics of JavaScript language.
Whenever we receive a non-primitive value for an operation where a primitive type was expected, ToPrimitive abstract operation is invoked.
For any non-primitive, ToPrimitive invokes two methods: valueOf() and toString(). Depending upon the hint passed, valueOf() followed by toString() is invoked for the ‘number’ hint , and vice versa for “string”.

Conclusion:

Dynamic nature of JavaScript is one of its core features. Understanding how coercion works internally can help us write robust code. Every language has some quirks and it’s our responsibility as a developer to be mindful of these caveats. Instead of finding flaws, we need to strive for learning the semantics of the language and work towards it.

Hope you liked the article and if that’s a boolean true, a few ❤️ will make me smile 😍.

Why do we need to bind methods inside our class component’s constructor?

Amandeep Singh — Mon, 19 Aug 2019 09:30:09 +0000

If we go back into the time where the hooks were not yet born, we will inevitably encounter this code while creating a React class component.

class MyClassComponent extends React.Component {
  constructor(props) {
    super(props);

    // Assuming that you need to pass this as a prop to one of a child component
    this.someMethod = this.someMethod.bind(this); // But why? 🤔
  }
 ... 
}

This is because whenever inside a class component when we need to pass a function as props to the child component, we have to do one of the following:

Bind it inside the constructor function.
Bind it inline (which can have some performance issues).
Use arrow function (which is the same as property initializer syntax).

Have you ever wondered why it has to be this way? Why we have to do this extra piece of work?

Through this article, I will first try to explain the binding inside the constructor function. Once we acquire that knowledge, we will try to answer why arrow functions don’t follow the same ceremony.

One thing we need to know that binding in the constructor has nothing to do with React. It’s purely related to how JavaScript implements this. Let’s look at the following code:

var x = 10;
let foo = {
  x: 90,
  getX: function() {
    return this.x;
  }
};

foo.getX(); // prints 90

let xGetter = foo.getX;

xGetter(); // prints 10;

When we initialised x into a global scope, it becomes the property of the window object (assuming that it’s a browser environment and not a strict mode). We can assert that:

window.x === 10; // true

this will always point to the object onto which the method was invoked. So, in the case of foo.getX(), this points to foo object returning us the value of 90. Whereas in the case of xGetter(), this points to window object returning us the value of 10.

To retrieve the value of foo.x, we can create a new function by binding the value of this to foo object using Function.prototype.bind.

let getFooX = foo.getX.bind(foo);
getFooX(); // prints 90

Armed with this knowledge, let’s try to understand what happens when you pass a function prop into the child component.

In the following code example, we have created a dummy class component to mimic React Component mental model. Inside the render function, we are returning a plain JS object which has a functional prop called 'onClick'.

The React element is just an immutable description object with
two fields: type: (string | ReactClass) and props: Object

class Component {
  constructor() {
    this.state = 10;
    this.setState = function() {
      console.log('state');
    };
  }

  handleClick() {
    this.setState();
  }

  render() {
    // return a child component.
    return {
      type: 'button',
      props: {
        // pass functional props
        onClick: this.handleClick,
        children: 'Click Me'
      }
    };
  }
}

// 1. creating a component instance
const componentInstance = new Component();

// 2. calling a render method on the instance
// ( In reality, React does the same thing for your class components)
const element = componentInstance.render();

// 3. calling the onClick function, which was passed as a  prop,
// will throw a 'TypeError: this.setState is not a function'.
element.props.onClick();

This TypeError is obvious now because this is pointing to the props object which doesn’t know the existence of any setState function. The setState function is only a property of componentInstance.

So, to fix this problem, we have to bind the handleClick function inside the constructor:

// inside constructor function
constructor() {
  // bind returns a new function
  this.handleClick = this.handleClick.bind(this);
}

...

// calling onClick will print 'state' this time.
element.props.onClick();

Now, the value of this will always point to componentInstance which has setState as one of its property and it will not throw any TypeError.

Now, that was the answer to our first question. It’s good progress so far. Moving forward, we shall try to find out the answer to our second question.

Looking at the code below:

let bar = { someMethod: function() { return this; } };

bar.someMethod(); // print {someMethod: f}

let foo = { someMethod: () => this};

foo.someMethod(); // prints global 'window' object

shows that arrow functions have no this of their own. It is always determined by the scope surrounding the arrow function when it was created.

Arrow functions have no this of their own.

When we use an arrow function inside our class (using property initializer feature), it becomes the method property of the instance. As this will always be determined by the outer scope, it will point to the instance of the class. Let’s see that in action:

class Component {
  constructor() {
    this.state = 10;
    this.setState = function() {
      console.log('state');
    };
  }

  // using fat arrow function; no binding require inside constructor
  handleClick = () => {
    // this will now point to the instance of Component class which knows about the setState method property
    this.setState();
  };

  render() {
    // return a child component.
    return {
      type: 'button',
      props: {
        // pass functional props
        onClick: this.handleClick,
        children: 'Click Me'
      }
    };
  }
}
// 1. creating a component instance
const componenttInstance = new Component();

//  2. calling a render method on the instance ( In reality, React does the same thing for your class components)

const element = componenttInstance.render();

// 3. calling onClick will now print 'state' to the console.
element.props.onClick();

I hope you have enjoyed reading this article and now will be able to answer the question confidently. I highly recommend reading this article by Dr. Axel Rauschmayer for a more detailed description of how this works.

Thank you for reading, and if you liked the article a few ❤️ will definitely make me smile 😍.

How to write 90% cleaner code with Hooks 🎣

Amandeep Singh — Sun, 28 Jul 2019 11:16:01 +0000

The year 2018 brought a lot of new features into the React Ecosystem. The addition of these features is helping developers to focus more on user experience rather than spending time writing code logic.

It seems that React is investing more towards a functional programming paradigm, in a search of great tools for building a UI which is more robust and scalable.

At ReactConf October 2018, React announced a proposal API called Hooks which took the community by storm. Developers started exploring and doing experiments with them and it received great feedback in the RFC (Requests for comments). React 16.8.0 is the first release to support Hooks 🎉.

This article is my attempt to explain:

Why hooks were introduced
How can we prepare ourselves for this API
How can we write 90% cleaner code by using React Hooks 🎣

If you just want to have a feel of this new API first, I have created a demo to play with. Otherwise, let’s get started by looking at 3 major problems we are facing as of now:

1. Reusing Code Logic

You all know that reusing code logic is hard and it requires a fair bit of experience to get your head around. When I started learning React about two years ago, I used to create class components to encapsulate all my logic. And when it comes to sharing the logic across different components I would simply create a similarly looking component which would render a different UI. But that was not good. I was violating the DRY principle and ideally was not reusing the logic.

The Old Way

Slowly, I learned about HOC pattern which allowed me to use functional programming for reusing my code logic. HOC is nothing but a simple higher order function which takes another component(dumb) and returns a new enhanced component. This enhanced component will encapsulate your logic.

A higher order function is a function that takes a function as an argument, or returns a function.

export default function HOC(WrappedComponent){
  return class EnhancedComponent extends Component {
   /*
     Encapsulate your logic here...
   */

    // render the UI using Wrapped Component
    render(){
      return <WrappedComponent {...this.props} {...this.state} />
    }
  }

  // You have to statically create your
  // new Enchanced component before using it
  const EnhancedComponent = HOC(someDumbComponent);

  // And then use it as Normal component
  <EnhancedComponent />

Then we moved into the trend of passing a function as props which marks the rise of the render props pattern. Render prop is a powerful pattern where “rendering controller” is in your hands. This facilitates the inversion of control(IoC) design principle. The React documentation describes it as a technique for sharing code between components using a prop whose value is a function.

A component with a render prop takes a function that returns a
React element and calls it instead of implementing its own render logic.

In simple words, you create a class component to encapsulate your logic (side effects) and when it comes to rendering, this component simply calls your function by passing only the data which is required to render the UI.

export default class RenderProps extends Component {
/*
  Encapsulate your logic here...
*/

  render(){
    // call the functional props by passing the data required to render UI
    return this.props.render(this.state);
  }
 }

// Use it to draw whatever UI you want. Control is in your hand (IoC)
<RenderProps render={data => <SomeUI {...data} /> } />

Even though both of these patterns were resolving the reusing code logic issues, they left us with a wrapper hell problem as shown below:

So, to sum it up we can see there are a few problems associated with reusing code logic:

Not very intuitive to implement
Lots of code
Wrapper hell

2. Giant Components

Components are the basic unit of code reuse in React. When we have to abstract more than one behaviour into our class component, it tends to grow in size and becomes hard to maintain.

A class should have one and only one reason to change,
meaning that a class should have only one job.

By looking at the code example below we can deduce the following:

export default class GiantComponent extends Component {
  componentDidMount(){
    //side effects
    this.makeRequest();
    document.addEventListener('...');
    this.timerId = startTimer();
    // more ...
  }

  componentdidUpdate(prevProps){
   // extra logic here
  }

  componentWillUnmount(){
    // clear all the side effects
    clearInterval(this.timerId);
    document.removeEventListener('...');
    this.cancelRequest();
  }
  render(){ return <UI />; }

Code is spread across different life cycle hooks
No single responsibility
Hard to test

3. Classes are Hard for Humans and Machines

Looking at the human side of the problem, we all once tripped trying to call a function inside a child component and it says:

TypeError: Cannot read property 'setState' of undefined

and then scratched our head trying to figure out the cause: that you have forgotten to bind it in the constructor. So, this remains the topic of confusion even among some experienced developers.

this gets the value of object who invokes the function

Also, you need to write lots of boilerplate code to even start implementing the first side effect:

extends -> state -> componentDidMount -> componentWillUnmount -> render -> return

Classes are also hard for machines for the following reasons:

Minified version won’t minify method names
Unused methods won’t get stripped out
Difficult with hot reloading and compiler optimisation

All the three problems we discussed above are not three distinct problems but these are symptoms of one single problem and that is React has no stateful primitive simpler than class component.

With the advent of the new React Hooks proposal API, we can solve this problem by abstracting our logic completely outside of our component. In fewer words, you can hook a stateful logic into the functional component.

React Hooks allow you to use state and other React features without writing a class.

Let’s see that in the code example below:

import React, { useState } from 'react';

export default function MouseTracker() {

  // useState accepts initial state and you can use multiple useState call

  const [mouseX, setMouseX] = useState(25);
  const [mouseY, setMouseY] = useState(25);

  return (
    <div>
      mouseX: {mouseX}, mouseY: {mouseY}
    </div>
  );
}

A call to useState hook returns a pair of values: the current state and a function that updates it. In our case, the current state value is mouseX and setter function is setMouseX. If you pass an argument to useState, that becomes the initial state of your component.

Now, the question is where do we call setMouseX. Calling it below the useState hook will cause an error. It will be the same as calling this.setState inside render function of class components.

So, the answer is that React also provides a placeholder hook called useEffect for performing all side effects.

import React, { useState } from 'react';

export default function MouseTracker() {

  // useState accepts initial state and you can use multiple useState call
  const [mouseX, setMouseX] = useState(25);
  const [mouseY, setMouseY] = useState(25);

  function handler(event) {
    const { clientX, clientY } = event;
    setMouseX(clientX);
    setMouseY(clientY);
  }
  useEffect(() => {
    // side effect
    window.addEventListener('mousemove', handler);

    // Every effect may return a function that cleans up after it
    return () => window.removeEventListener('mousemove', handler);
  }, []);

  return (
    <div>
      mouseX: {mouseX}, mouseY: {mouseY}
    </div>
  );
}

This effect will be called both after the first render and after every update. You can also return an optional function which becomes a cleanup mechanism. This lets us keep the logic for adding and removing subscriptions close to each other.

The second argument to useEffect call is an optional array . Your effect will only re-run when the element value inside the array changes. Think of this as how shouldComponentUpdate works. If you want to run an effect and clean it up only once (on mount and unmount), you can pass an empty array ([]) as a second argument. This tells React that your effect doesn’t depend on any values from props or state, so it never needs to re-run. This is close to the familiar mental model of componentDidMount and componentWillUnmount. If you want a deep dive into useEffect hook, I've written another article here.

But isn’t our MouseTracker component still holding the logic inside? What if another component wants to share mousemove behaviour as well? Also, adding one more effect (e.g window resize) would make it little hard to manage and we are back to the same problem as we saw in class components.

Now, the real magic is you can create your custom hooks outside of your function component. It is similar to keeping the logic abstracted to a separate module and share it across different components. Let see that in action.

// you can write your custom hooks in this file
import { useState, useEffect } from 'react';

export function useMouseLocation() {
  const [mouseX, setMouseX] = useState(25);
  const [mouseY, setMouseY] = useState(25);

  function handler(event) {
    const { clientX, clientY } = event;
    setMouseX(clientX);
    setMouseY(clientY);
  }
  useEffect(() => {
    window.addEventListener('mousemove', handler);

    return () => window.removeEventListener('mousemove', handler);
  }, []);

  return [mouseX, mouseY];
}

And now we can clean up our MouseTracker component code (90%) to a newer version as shown below:

import React from 'react';
import { useMouseLocation } from 'customHooks.js';

export default function MouseTracker() {

  // using our custom hook
 const [mouseX, mouseY] = useMouseLocation();

  return (
    <div>
      mouseX: {mouseX}, mouseY: {mouseY}
    </div>
  );
}

That’s kind of a “Eureka” moment! Isn’t it?

But before settling down and singing praises of React Hooks, let’s see what rules we should be aware of.

Rules of Hooks

Only call hooks at the top level
Can’t use hooks inside a class component

Explaining these rules are beyond the scope of this article. If you’re curious, I would recommend reading React docs and this article by Rudi Yardley.

React also has released an ESLint plugin called eslint-plugin-react-hooks that enforces these two rules. You can add this to your project by running:

# npm 
npm install eslint-plugin-react-hooks --save-dev

# yarn 
yarn add eslint-plugin-react-hooks --dev

This article was part of my talk at the ReactSydney meetup December 2018. I hope this article has intrigued you to give React hooks a try. I am super excited about the React roadmap which looks very promising and has the potential to change the way we use React currently.

You can find the source code and demo at this link.

If you liked the article, a few ❤️ will definitely make me smile 😀. There's more to come.

Hidden gems of debugging 💎

Amandeep Singh — Tue, 23 Jul 2019 07:49:18 +0000

Anything that cuts some of your arduous task time is good for your productivity. Debugging is one of those strenuous tasks. Developers strive to write bug-free code, but we all know that it’s not easy. No one likes to see bugs in their code—those red color lines are not very appealing, right? Nonetheless, errors are good if you happen to catch them early. Debugging them properly will give you new learning and a feeling of satisfaction. There were countless moments when I learned a lot while debugging my own code and seeing how it could challenge my own concepts.

We all learn by making mistakes, and make mistakes again to learn more.

Enough of motivation. Let's get to business.

Today, I am going to share some of the tricks and tips you could use to supercharge your debugging skills. I've only tried these tricks in chrome dev tools (sorry FireFox users), but some of them are browser agnostic.

1. Using shorthand object property value notation in console.log

This is my favourite console.log trick and has to be on top of the list. You must have written torrents of console statements in your code base trying to figure out the value of a variable. The Convenience of use has made "console" the leader of the debugging championship 🏆. The golden line looks like this:

 console.log(a);

This is awesome and you get to open up your console dev tool to see the value. But, as the number of lines grows, it becomes hard to trace the reference of that particular value.

 console.log(a); // prints 20
 console.log(b); // prints 30
 console.log(c); // prints 40
// Sorry what was the reference variable for '30'? I am kind of lost😕

A very obvious solution to this would be to dump in some string representation along with your variable. Thanks to the versatile nature of console.

 console.log('a', a); // prints a 20
 console.log('b', b); // prints b 30
 console.log('c', c); // prints c 40

But as I said, we need to cut time and write fewer lines to be more efficient and productive, right? So, the trick is to wrap your variable inside the curly '{}' braces. This is really not a trick but a language feature know as object property value shorthand notation. You can learn more about it here.

  // use object shorthand property value notation
  console.log({ a }); // prints { a: 20 };
  console.log({ b }); // prints { b: 30 };

Doing so, will give you the reference variable along with its value. Less code more value.

Bonus: Use 'var' instead of 'const' or 'let' when declaring variables inside your chrome's console tab to avoid annoying Syntax Error. 'var' is your scratchpad buddy.

2. No more wrapping of curly braces for fat arrow functions

You must have used fat arrow function by now (if you haven't, you should start using it). They are short and precise and omit the requirement of the curly braces and return statement when writing your function definition.

   const foo = x => 2 * x; // how awesome is that 😊

A popular use case would be inside the array utility callbacks (map, filter, reduce, etc)

   let arr = [1, 2, 3];
   let newArr = arr.map(el => el * el); // [1, 4, 9]

Now, let say if you want to debug the map callback function, how would you go about printing the el value? A simple answer would be to refactor the callback and throw in some curly braces around and inject return statement.

 let arr = [1, 2, 3];

 // using curly braces and return statement
 let newArr = arr.map(el => {
  console.log({ el }); // prints {el: 1}, {el: 2}, {el: 3}
  return el * el;
});

What! are you kidding me 🙈? This is not ideal. Not only it's time-consuming, but reverting back will consume more time too. A better solution is something like this:

   let arr = [1, 2, 3];

   // more concise and inline 🎉
   let newArr = arr.map(el => console.log({ el } ) ||  el * el);

Whoa!! what was that? Don't worry, it's just JavaScript. I'll explain:

There are two things going on here:

console.log() always returns undefined which is a falsy value.
Given a statement like expr1 || expr2, Logical OR operator (||) returns expr1 if it can be converted to true; otherwise, returns expr2.

So, return value of console.log({ el }) was undefined and thus second expression el * el was executed. The beauty about this change is that you get to see the value inline. No debugger or cumbersome curly ceremony is required. A big win, right? 😊

This is very handy when you are a fan of functional programming and use a library like Ramda.

3. Add logpoints—less sprinkling of console.log in your code

The console.log has become an indispensable part of our debugging journey. We tend to sprinkle it everywhere in our code; it has become our first line of defense against bugs.
The problem is time consumption while cleaning up these logs statements. You can obviously go and find each console statement and remove them manually. But what if I say there's a better solution? Embrace new kid in the town—The logpoint.

Google has added this feature in Chrome 73. It allows you to add console statement in your source code straight from your dev tool.

Steps:

Open Sources section of your dev tool and locate your source code.
Write click on any of the line numbers you want to add your console statements.
A list of options will come up; select Add logpoint.
A Breakpoint editor will show up allowing you to enter the variable name. It's similar to how you write your expression inside console.log() function.
Enter a shorthand property notation trick I showed you above. Click outside the editor or hit Enter to save.
An orange badge will represent your Logpoint and you are all set.

Now, every time your script is executed, you will see the values being logged out at the console section of your dev tool. You can add multiple log points.

Action speaks louder than words:

Bonus: You can also use conditional breakpoint feature to insert a breakpoint when the condition evaluates to true.

4. Store and copying

Chrome dev tool is where I spend most of my time debugging. I use it as my JavaScript scratchpad. It has lots of in-built features at our disposal. One of the cool feature, that has been so helpful for me, is copying the variable value into my clipboard.

To copy any reference variable, for example, x, into your clipboard, just type copy(x) into the console tab and hit Enter. Chrome will copy that variable into your clipboard and you can paste it anywhere by using normal paste command.

The big benefit comes into picture when you are playing around with network response. Here you can combine this copy feature with another excellent feature called store as global variable.

Let's see that in action:

Open your Network tab and select a request from the list.
Open up the Preview section on your right.
Right-click the property name and select Store as a global variable.
The variable will be shown in your console tab, and you can use copy() function to have it in your clipboard.

Kill two birds with one stone.

Bonus: You can use 'Ctrl + f' to search for a particular string match over the entire response object in the preview section.

5. The Breakpoint for your network requests

Ideally, you should strive to keep your HTTP requests as minimum as possible while building your client. Not only it gives you a smooth performance but also helps to avoid bugs.

In one of our project at Insurance Company, we were building a data-driven UI. Every next question in the form was driven by the user's previous actions and was fetched subsequently over the wire.
We needed to analyse that when a particular kind of request was triggered, we could debug the request payload accurately. I ended up finding this awesome solution called XHR/fetch Breakpoints. It allowed me to put a conditional breakpoint on my fetch requests.

XHR Breakpoints allow you to put breakpoints on all of your network requests. But the real power is the ability to apply breakpoint via 'URL contains' section. You can throw in any keyword there and chrome will put a pause when it encounters the request URL containing the matching word. How awesome is that!!

Steps are:

Open Sources tab of your dev tool and on the right-side panel.
You should see XHR/fetch Breakpoint section below Breakpoints.
Hit + button and a Breakpoint editor should come up asking you to enter the keyword.
Enter your keyword and hit Enter.

6. Copying your request as cURL

This is handy when you want to trigger your request from a command line too like cmd or bash. You can also paste the copied link into your Postman app and it will fill up all the request headers for you. Very handy in visualising your request.

Open you Network tab inside your chrome dev tool.
Locate the request you want to copy and right-click to bring multiple options.
Hovering over the Copy options will show you a list of a different format you can copy your request as.
Select Copy as cURL and it will be saved into your clipboard.

7. Don't let go off your CSS changes—persist styling when refreshing

This tip is dedicated to our UI/Designers friends. We know that via Styles section of Elements tab, we can modify the CSS. But these changes don't persist when you refresh the page. If you wish to persist the modification you made to the existing stylesheet, you can do this via the following steps:

Open Sources tab and select Overrides.
Click Select folder for overrides and select a folder where you want to save your changes.
A permission dialogue would pop up asking for permission. Go ahead and allow.
Select your folder and you are all set to rock 'n' roll.

Now every time you make changes to your existing styles, they won't disappear even when you refresh the page.

Note: Adding new style changes won't persist though!.

Final thoughts

You can't change the fact that it's practically impossible to write a 100% bug-free code. Rather than slamming your head against your desk, let's adapt and develop our debugging skills. Believe me, you will learn a lot by exploring the root causes of your bugs.

If you liked the article, a few ❤️ will definitely make me smile 😀. Now, go and ~~kill~~ remove some bugs now 🐞.

DEV Community: Amandeep Singh

Thinking about accessibility—a few tips to make a difference

Table of contents

Use semantic elements where possible

Don't use divs for creating a button

Use 'skip to main content' link

Don't forget the focus state

Never miss the 'alt' tag on your image

Link text should describe the purpose of the link

No ARIA is better than Bad ARIA

Implementing your custom UI widgets

Use 'lang' attribute to define the language of the page, and element

Use jest-axe to automate your a11y tests

Use CSS to highlight the accessibility issues

Using Icon only as button

VisuallyHidden React component

Color contrast

Accessibility checklist

Learn to operate VoiceOver on your Mac

Use a11y eslint plugin as your dev dependency

Use ARIA live regions to announce dynamic changes in the page

Zoom up the page to 200% and see if you can still use the website

Chrome/FireFox extensions

Read articles on accessibility, follow blogs/newsletters

It's not only about the UI

Conclusion

Lazy-loading React components—no rocket science

Route-based splitting

Component-based splitting

Lazy-loading via React.lazy

Lazy-loading in NextJS

Conclusion

Curated list of Newsletters to level up your coding skills

Taking one step forward

1. CSS, HTML

2. JavaScript

3. Accessibility, UX, Design

4. ReactJS

5. NodeJS

6. GraphQL

7. Web Dev & Tips

8. Career Growth

Conclusion

Are you sure you know how an event propagates in JavaScript?

Event propagation

Stopping the event propagation

Useful resources:

An Easy Explanation to Prototypal Delegation in JavaScript

Prototypal Delegation

Constructor function and the new keyword

Closing thoughts

How to smartly cleanup your commit history using git reset?

TLDR

Pointers 👈

It's cleanup time ⏰

Closing thoughts 👋

Git Interactive—enhance your work productivity 10X

1. Interactive Staging

Explanation

Use Cases

Add smaller commits

Handy while debugging and refactoring

2. Interactive checkout

Explanation

Use Cases

Keeping your working directory clean

Handy while debugging

What’s the deal with Object.prototype.hasOwnProperty.call()?

1. Object.prototype

2. Borrowing a function

3. Object.prototype.hasOwnProperty vs instance.hasOwnProperty

Summary

Abstract Operations—the key to understand Coercion in JavaScript

JavaScript Type System

Coercion

Abstract Operations

ToString

ToNumber

ToBoolean

ToPrimitive