DEV Community: Farzad YZ

A simpler approach to registering and clearing DOM event handlers

Farzad YZ — Tue, 28 Dec 2021 12:27:09 +0000

originally published at: https://farzadyz.com/blog/a-simpler-approach-to-registering-and-clearing-dom-event-handlers

DOM event handlers work with a strange interface if you ask me. The fact that you need to
keep the reference to the event handler to be able to clear it is not practical, especially if you're
trying to handle more than a single event handler. Imagine building a command palette or keyboard shortcuts into your application and having to
keep a reference to a ton of handler variables. This is a recipe for uncontrolled growth. Sure, you can keep a key-value
pair of events to their respective handlers, but that feels like reinventing browser internals.

When you get to clearing event handlers, it gets event better! You'll have to pass the same exact arguments, only this time to removeEventListener to clean the handler. Take a look at this example:

const clickHandler = () => {
  console.log("clicked");
};
element.addEventListener("click", clickHandler);
// You MUST pass the same reference to the handler because the event registry saves them by reference
// If you lose the reference or pass the handler function directly to `addEventListener`, there would be no way to clear it
element.removeEventListener("click", clickHandler);

It could be a tedious process to have to keep a reference to a handler function just to be able to clear it later on in the code, especially considering that subscriptions are usually a part of a bigger code. It's a path towards declaring too many variables or spamming a larger object.

But how can we make this simpler?

A common pattern to make subscription clearance simpler is to return a function that, once called, clears the subscription automatically. This is a well known pattern used by many libraries. You've already seen this in React's useEffect where useEffect expects you to return a function for clearing subscriptions inside the effect. Or how XState expects you to return a clearance function from invocations.

To make clearing easier, we can write a tiny handy function that follows the same pattern.

Let's start with DOM event listeners.

// ...args: [event, handler, capture]
function onEvent(element, ...args) {
  element.addEventListener(...args);
  return () => {
    element.removeEventListener(...args);
  };
}

Here is how you can use the code above:

<form>
  <div>
    <label for="name">Name</label>
    <input id="name" name="name" />
  </div>
  <button>Submit</button>
</form>

<script>
  const $form = document.querySelector("form");
  const onSubmit = (e) => {
    // post to server
  };
  const clearSubmit = onEvent($form, "submit", submitForm);

  // When needed to clear it
  clearSubmit();
  // as apposed to $form.removeEventListener('form', submitForm)
</script>

Make it type-safe

To use a type-safe version of our utility from above, we can borrow most of the typing from Typescript's DOM types.

function onEvent<E extends HTMLElement>(
  element: E,
  ...args: Parameters<HTMLElement["addEventListener"]>
) {
  element.addEventListener(...args);
  return () => {
    element.removeEventListener(...args);
  };
}

We use a generic type to keep our element type flexible as we don't know for sure what element it's going to be, but we limit to an element that extends HTMLELement.

To make the rest of arguments type-safe, we can basically get the definition from element.addEventListener already, since we're just passing the arguments through.

How is this useful?

First, it spares you a few lines of code for having to keep a reference to handlers.
Secondly, you no longer need to know what event it was, what element it's attached to or how the event was registered (other arguments). All you care about is calling a function that clears hanging subscriptions.

Detecting unique arrays in Javascript

Farzad YZ — Wed, 25 Dec 2019 01:19:05 +0000

When Javascript arrays contain primitive values (strings, numbers, undefined, null, booleans and Symbols), there might be cases in which you're willing to detect if the array contains any duplicated elements. in other words, you would want to determine if elements in the array are unique.

There are several approaches you can take to achieve this. let's take a closer look at our options.

Approach 1: Nested loops

In this approach, we will traverse the array, starting from the first element and for each element, we will compare this element to all the other elements to see if there is a match. to achieve this, we will use two for loops, nested into each other.

function isUnique(arr) {
  const len = arr.length;
  for (let i = 0; i < len; i++) {
    for (let j = 0; j < len; j++) {
      // if the elements match, this wouldn't be a unique array
      if (i !== j && arr[i] === arr[j]) {
        return false;
      }
    }
  }
  return true;
}

Although this approach works quite fine with small and semi-small datasets, as the input dataset grows, it gets slower and slower. The slowness of this approach is because of the nested loop. Imagine a dataset of a million numbers. in this dataset, in the worst case, our duplicated element could be the last element in the array and therefore, we would need to compare a million numbers to a million numbers (1 million * 1 million), which is quite slow.

https://jsfiddle.net/farskid/bquo7k8x/12/

Approach 2: Single loop with cached values

In this approach, instead of comparing each element to every other element, we will keep track of the elements we visit and weren't a match for a duplicated element. in other words, we cache what we traverse and just look them up for the next element to check if we've already visited such an element. Because of this visited reference, we only need to compare every element in the array to this reference and therefore, we have to traverse this array only once.

function isUnique(arr) {
  const seenValues = {}

  for (let i = 0; i < arr.length; i++) {
    // we already saw this element in the array
    if (seenValues[arr[i]]) {
      return false;
    } else {
      seenValues[arr[i]] = true
    }
  }

  return true;
}

in the worst case of a million numbers in a dataset, our duplicated element will be the last element but in this approach, we only compare 1 million times. This approach is significantly faster than approach 1. .

https://jsfiddle.net/farskid/zky1mdug/18/

Approach 3: using ES6 `set`

When ES6 came around, we were introduced to a new data structure in Javascript called Sets. Sets are collection of elements that are unique by definition, meaning that if you try to insert a duplicated element into a set, it won't have any effects.

Due to Sets being a collection of unique elements by definition, there is a technique to convert arrays into sets which in turn, results in a unique collection of items in that array, now stored into the set. then a reverse operation will be used to convert that Set back to an array.

In a sense, you could say, Set is used as an intermediate data structure to remove duplicated elements from the array.

Array -> Set -> Array

// convert an array to a set and convert back
function getUniqueArray(arr) {
  return [...new Set(arr)]
}

function isUnique(arr) {
  return getUniqueArray(arr).length === arr.length
}

in this approach, if the number of elements inside the unique array (converted back from Set) is the same as the input array length, it means this array has already been containing unique values and no duplicated values were removed from it to alter the length.

Note: You don't need to convert a Set back to array if you just want to check for uniqueness. You can skip this part of operation totally by checking Set.prototype.size.

// convert an array to a set
function arrayToSet(arr) {
  return new Set(arr)
}

function isUnique(arr) {
  return arrayToSet(arr).size === arr.length
}

Performance comparison

Using any of these 3 approaches interchangeably is fine as long as your dataset is relatively small. for larger datasets, you need to keep an eye on performance of these approaches and how many operations they could execute in a limited duration.

The short answer for performance comparison between these 3 is:

Approach 2 > Approach 3 > Approach 1.

Approach 2 (using single loop with cached values) is significantly faster than the rest. between approach 3 (Set) and approach 1 (Nested loops), approach 3 is also much faster.

To have a better understanding of these performance comparisons, take a look at this benchmark:

https://esbench.com/bench/5e0273c1170166009e5470f7

Side note for whoever is curious

Approach 1 (using nested loops) is of quadratic complexity, meaning that it will result in O(n^2) Time complexity.

Approach 2 (using single loop and cached values) is of linear complexity, meaning that it will result in O(n) Time complexity.

For approach 3, I won't have a strong opinion as I'm not fully aware of how Sets are being implemented in Javascript engines under the hood.

Conclusion for the impatient

Do not pre-optimize for a problem you don't have. Performance optimizations make sense only when you have a large dataset to bring slowness onto surface. for relatively small datasets, it won't matter which approach you take as all will behave fast enough. for larger datasets, always lean towards using approach 2 as benchmarks show it's significantly faster.

`useBackButton` hook to handle back button behavior in React Native

Farzad YZ — Mon, 12 Aug 2019 00:05:40 +0000

React hooks help with carrying stateful logic and keeping their lifecycle separate from the view layer lifecycle. They've been around since React v16.8 and since people have been avoiding class components in favor of hooks.

One of the somewhat interesting aspects of hooks is their flexibility in terms of composition and abstraction. If a code snippet using different built-in hooks is handling a part of logic that is separate and independent from other parts, it can be abstracted away as a Custom Hook.

useBackButton custom hook

To handle the behavior of hardware back button in Android and tvOS devices using React Native, there is BackHandler API that can assist in overriding the default behavior or patching it.

BackHandler takes an event-driven approach to offer an API, meaning that to subscribe to back button presses, you'll need to register an event listener.

import { BackHandler } from "react-native";

function backButtonHandler() {}

BackHandler.addEventListener("hardwareBackPress", backButtonHandler);

and of course, to de-register this subscription, you'll need to use removeListener, the same way we do so handling DOM events.

backButtonHandler.removeEventListener("hardwareBackPress", backButtonHandler);

use Hooks to utilize BackHandler

Subscriptions are side effects! therefore, we can use useEffect built-in hook to execute them. It's important to notice that useEffect requires us to return a function to remove the subscription once React is willing to clean up! Cleanups are usual when the component is being unmounted or one of the dependencies of the useEffect hook change, so React needs to clean up previous subscriptions of that hook and re-execute it!

function backButtonHandler() {}

function MyComponent() {
  useEffect(() => {
    BackHandler.addEventListener("hardwareBackPress", backButtonHandler);

    return () => {
      BackHandler.removeEventListener("hardwareBackPress", backButtonHandler);
    };
  }, [backButtonHandler]);

  return <View>...</View>;
}

useBackButton is born!

while the above code snippet works perfectly, copy-pasting it into all the screens might sound frustrating to some of us (we're freaks after all)! To help to remove our frustrations, React offers a way to build your custom hook.

/* ComponentA */
function backButtonHandlerForA() {}
function ComponentA() {
  // Frustration begins!
  useEffect(() => {
    BackHandler.addEventListener("hardwareBackPress", backButtonHandlerForA);

    return () => {
      BackHandler.removeEventListener(
        "hardwareBackPress",
        backButtonHandlerForA
      );
    };
  }, [backButtonHandlerForA]);

  return <ViewA />;
}

/* ComponentB */
function backButtonHandlerForB() {}
function ComponentB() {
  // Frustration begins!
  useEffect(() => {
    BackHandler.addEventListener("hardwareBackPress", backButtonHandlerForB);

    return () => {
      BackHandler.removeEventListener(
        "hardwareBackPress",
        backButtonHandlerForB
      );
    };
  }, [backButtonHandlerForB]);

  return <ViewB />;
}

A custom hook is just an abstraction to share the same logic between components and hooks, the same way we do this between functions in a regular programming.
Components are functions. Hooks are functions as well. You get the idea, right?!

In cases of ComponentA and ComponentB samples above, registration, removal and hook implementation are the same. it's just the handlers that can be different per component. So our custom hook needs to provide those common parts and only accept the changing part (handler per component) as an incoming argument.

/* useBackButton */
function useBackButton(handler) {
  // Frustration isolated! Yay! 🎉
  useEffect(() => {
    BackHandler.addEventListener("hardwareBackPress", handler);

    return () => {
      BackHandler.removeEventListener(
        "hardwareBackPress",
        handler
      );
    };
  /* now that the handler is an external dependency, once handler 
    changes, we wanna be able to reflect that change and update the 
    handler inside our hook too. so we need to pass handler as a 
    dependency to our custom hook
  */
  }, [handler]);
}

/* ComponentA */
function backButtonHandlerForA() {}
function ComponentA() {
  // utilize custom hook
  useBackButtton(backButtonHandlerForA);
  return <ViewA />;
}

/* ComponentB */
function backButtonHandlerForB() {}
function ComponentB() {
  // utilize custom hook
  useBackButtton(backButtonHandlerForB);

  return <ViewB />;
}

Recap

If you intend to share a common logic between components and built-in hooks, you can abstract that away by building your custom hook. Make sure to read the impressively detailed docs of Hooks and Rules of Hooks from the official docs.

Cheers!

Unit Testing Higher Order Components with Enzyme and Jest

Farzad YZ — Tue, 11 Jun 2019 22:17:20 +0000

Not all the components you write for your React application can be divided into Stateful and Stateless (dumb) categories. There is a 3rd advanced type of component in React called a higher-order component. A higher-order component is a function that takes a component as an argument and returns another component. Check out my other article to see how higher-order components are used in the real world.

Creating a HOC with Tests

We’ll be using Enzyme and Jest, but these concepts apply to any testing library.

One of the common HOCs I write for every project of mine is called withConditional. Its purpose is to render a component if and only if the condition passes, otherwise just return null.

import React from "react";
const withConditional = Component =>
  function withConditionalComponent({ condition, ...props }) {
    if (condition) {
      return <Component {...props} />;
    }
    return null;
  };
export default withConditional;

As you can see, when the condition passed to the HOC evaluates to true, it returns the component, otherwise, it returns null.

So how can you unit test the HOC? There are surprisingly minimal articles talking about unit testing these components, and I had a hard time figuring out the proper way. Recently the solution clicked!

Solution

To properly test these badass components, you just need to know that they are simple functions and that’s all!

withConditional is used in the following manner:

const ConditionalComponent = withConditional(MyComponent);
class HelloWorld extends React.Component {
  render() {
    return <ConditionalComponent condition={3 > 4} />;
  }
}

So, we should use the exact same concept to unit test them as well.

The important thing to take into account here is to test the component for all states. For instance, if our HOC can handle two different states, depending on the condition passed to it, then we MUST account for both states in the tests.

When the condition passes:

it("should render the component only when the condition passes", () => {
  const ConditionalComponent = withConditional(Component);
  const wrapper = shallow(<ConditionalComponent condition={true} />);
  expect(wrapper.html()).not.toBe(null);
});

When the condition fails:

it("should return null when the condition fails", () => {
  const ConditionalComponent = withConditional(Component);
  const wrapper = shallow(<ConditionalComponent condition={false} />);
  expect(wrapper.html()).toBe(null);
});

Have fun and test it up!

3 Ways to clone objects in Javascript

Farzad YZ — Tue, 11 Jun 2019 22:12:04 +0000

Cloning an object is somewhat a task that is almost always used in any project from a simple one to the most complicated ones. As it may seem simple for not seasoned Javascript developers, it actually has some pitfalls that would hurt you in the bones if you didn’t know the proper way to do it.

Talk is cheap, show me the code

The first way that could cross a developer’s mind is to deeply iterate through the source object’s properties and copy them one by one on the target object. As it may seem good at the beginning, it is not a performance friendly solution and a potential bottleneck when it comes to large and deep objects.

1: Shallow copy using iteration

function iterationCopy(src) {
  let target = {};
  for (let prop in src) {
    if (src.hasOwnProperty(prop)) {
      target[prop] = src[prop];
    }
  }
  return target;
}
const source = { a: 1, b: 2, c: 3 };
const target = iterationCopy(source);
console.log(target); // {a:1, b:2, c:3}
// Check if clones it and not changing it
source.a = "a";
console.log(source.a); // 'a'
console.log(target.a); // 1

So as you see, it’s working!

Now let’s cut the chase to the second solution which is indeed more elegant but, more limited to use.

2: Converting to JSON and back

function jsonCopy(src) {
  return JSON.parse(JSON.stringify(src));
}
const source = { a: 1, b: 2, c: 3 };
const target = jsonCopy(source);
console.log(target); // {a:1, b:2, c:3}
// Check if clones it and not changing it
source.a = "a";
console.log(source.a); // 'a'
console.log(target.a); // 1

Note: Be careful about using this method as your source object MUST be JSON safe. So it may need some sort of exception handling to keep it safe in cases in which the source object is not convertible to JSON.

3: Using `Object.assign`

Update: This method has a flaw that it only does a shallow copy. It means that nested properties are still going to be copied by reference. Be careful about it.

This way is the best and the safest way I personally consume in my projects. It’s leveraging a built-in static method on the Object object and is handled and provided by the language. So use this one!

function bestCopyEver(src) {
  return Object.assign({}, src);
}
const source = { a: 1, b: 2, c: 3 };
const target = bestCopyEver(source);
console.log(target); // {a:1, b:2, c:3}
// Check if clones it and not changing it
source.a = "a";
console.log(source.a); // 'a'
console.log(target.a); // 1

Conclusion

You must know that every framework and including libraries such as Lodash and Underscore has a way to support cloning objects. Almost all of them used a more complex version of iterationCopy before ES6 was introduced. On ES6+ environments, there is language support for Object.assign, so try to use the most out of it. As a rule of thumb, always try to use the 3rd solution and avoid the JSON solution.

Keep calm and clone objects without any hesitation 😊

Cross-Domain Iframe-parent communication

Farzad YZ — Tue, 11 Jun 2019 21:58:29 +0000

There are many cases iframe would be a good solution to use. Although they are kind of dead to HTML and not a lot of developers use it, It could come up to you as a solution to a complicated problem some day.

Knowing a way to communicate through an iframe to parent is such a valuable and time saver. Maybe iframe could tell it’s parents when it’s content is ready or engage user interactions inside an iframe with the parent to react properly.

Some days ago at my company, we had a Wordpress website that loaded an iframe for choosing a plan to buy virtual machines as shown below.

I was assigned a task to do something challenging on this element. The company intended to open a URL on click of the orange button, BUT because the button was inside the iframe, that couldn’t be managed easily.

First thing I tried to was to use postMessage to send a message from iframe to its parent. I came up with this code:

<iframe src="Path/To/Html"><button id="my-btn">Start</button></iframe>

document
  .getElementById("my-btn")
  .addEventListener("click", handleButtonClick, false);
function handleButtonClick(e) {
  window.parent.postMessage("iframe_message");
}

And also listen to the message on the parent window:

window.addEventListener('iframe_message', function() {
window.open('some url', '_blank')
}, false

It was perfect! worked like a charm. It passed some minutes until I figured out the actual problem. This only worked for same-domain iframes. Apparently, cross-domain iframes don’t post message to the parent properly.

I dogged the web a lot and found a really interesting inspiration on a dark edge of stackoverflow. Although It did not help me, It fixed me in the right direction. The solution was to use customEvents.

So I refactored the solution to:

document
  .getElementById("my-btn")
  .addEventListener("click", handleButtonClick, false);
var myEvent = new CustomEvent("my_event", { detail: { url: "some url" } });
function handleButtonClick(e) {
  window.parent.dispatchEvent(myEvent);
}

And listen to it on the parent of course:

window.addEventListener(
  "iframe_message",
  function(e) {
    var url = e.detail.url;
    window.open(url, "_blank");
  },
  false
);

It was amazing as I could easily pass custom data from iframe to the parent window.

Conclusion

Dealing with iframes is Hard. It’s not intended to be used unless there is no other way to do it.

If you’re using a same-domain iframe, you’re in heaven. You could easily control iframe’s content and also communicate to its parent through postMessage.

But you’re in Hell when it gets cross-domain. You could only use CustomEvent and dispatchEvent on the iframe and listen to it on the parent window. In this case, try to modularize your communication protocol and pass custom data.

DEV Community: Farzad YZ

A simpler approach to registering and clearing DOM event handlers

But how can we make this simpler?

Make it type-safe

How is this useful?

Detecting unique arrays in Javascript

Approach 1: Nested loops

Approach 2: Single loop with cached values

Approach 3: using ES6 set

Performance comparison

Side note for whoever is curious

Conclusion for the impatient

`useBackButton` hook to handle back button behavior in React Native

useBackButton custom hook

use Hooks to utilize BackHandler

useBackButton is born!

Recap

Unit Testing Higher Order Components with Enzyme and Jest

Creating a HOC with Tests

Solution

When the condition passes:

When the condition fails:

3 Ways to clone objects in Javascript

Talk is cheap, show me the code

1: Shallow copy using iteration

2: Converting to JSON and back

3: Using Object.assign

Conclusion

Cross-Domain Iframe-parent communication

Conclusion

Approach 3: using ES6 `set`

3: Using `Object.assign`