You are viewing the Articles in the ES+ Category

Simplified Error Handling with Error Causes

Exception handling is a critical aspect to ensuring the reliability and resilience of a system. Perhaps of equal importance is the ability for developers to easily debug exception traces back to a root cause. In JavaScript, however, traditionally this process has often required rather convoluted solutions which lead to intricate patterns that ultimately continued to obscure the underlying root cause. Fortunately, with the introduction of the error.cause property, JavaScript debugging has now taken a significant step forward towards simplifying this process, providing native capabilities which facilitate improved error traceability.

In the legacy paradigm, JavaScript’s error handling was akin to a labyrinth, often requiring developers to traverse a complex maze of stack traces in order to pinpoint the origin of an issue. This often necessitated verbose logging mechanisms, which, while somewhat effective, still lacked fundamental standardization and tended to introduce additional layers of complexity which must be integrated within a system, and understood by team members.

While error cause contexts have been available in numerous other languages such as Rust/WASM, Python, etc. in JavaScript, historically speaking, such a facility has been unavailable. Thus, to mitigate these short-comings, developers would need to resort to basic workarounds such as appending custom properties to re-thrown errors or appending error messages. Although these solutions provided a makeshift bridge to identify error causes, they were rather convoluted at best, and often led to fragmented and inconsistent implementation which never truly solved the problem at hand.

The error.cause property heralds a new era, providing a streamlined approach to attach and propagate the underlying cause of an error, offering a standardized approach for encapsulating the origin of subsequent errors.

Consider the traditional approach where a custom property might have been used to include information related to the originating error:

With error.cause, the same can be now achieved natively while retaining the full stack trace back to the origin root cause:

The benefits of adopting error.cause are manifold, resulting in a significant improvement to Developer Experience though native error traceability. A few key benefits include:

Clarity: Provides a clear lineage of errors, akin to a well-documented review process, making it much easier to understand the flow of exceptions.

Consistency: Promotes a more uniform error handling mechanism across applications.

Simplicity: Reduces the need for additional error handling constructs, streamlining error propagation and handling.

As with countless other language enhancements, the introduction of the error.cause property is a testament to JavaScript’s evolution, offering developers a robust and simplified error handling mechanism; supporting more reliable facility for error tracing, reshaping the way debugging and exception management can be approached.

ES2020 Optional Chaining & Nullish Coalescing

Of the various Features proposed in ES2020, perhaps two of the simplest features will prove to be the most useful, at least in terms of simplification and maintenance are concerned.

Specifically, the Optional Chaining Operator and Nullish Coalescing Operator are of particular interest as they are certain to result in less verbose, less error prone expressions.

In a nutshell, Optional Chaining provides a syntax for undefined / null checks when performing nested object references using a simple question mark appended by a dot (?.) notation.

For instance, consider how many times you may have written defensive expressions similar to the following:

Or perhaps you have assigned intermediate values to temporary variables to perform the same:

The need to check for possible reference errors quickly becomes tedious, and with each lookup we increase the potential for introducing bugs. Utilities can be implemented for delegating these checks, but ultimately, this just moves the problem from one context to another, resulting in additional points for failure.

With Optional Chaining, however, accessing properties safely becomes considerably less verbose, as the examples above can be simplified to:

Reference checks when invoking functions also become simplified:

And dynamic property references can safely be performed as well:

In addition, combined with the Nullish Coalescing Operator, Optional Chaining becomes even more succinct as one can specify a value to resolve to rather than the default (undefined) by simply using a double question mark (??) notation. For example:

Moreover, Nullish Coalescing, while intended as a compliment to Optional Chaining, also solves additional problems when dealing with falsy values. For instance, consider how many times you may have written something similar to the following:

With the Nullish Coalescing Operator, we can avoid the problems outlined above as only undefined and null values will evaluate to true, so falsy values are safe:

Since Nullish Coalescing only checks for undefined and null, the above holds true for all other falsy values, so false, empty strings, and NaN are safe as well..

One thing to note is that Optional Chaining does not resolve when destructuring. So, for example, the following will throw an exception:

Interestingly, though, combined with Nullish Coalescing, an exception will not be raised; though, the default will not be assigned, either:

As can be seen, ES2020 has no shortage of new features on offer to be excited about and, while arguably not as exciting as other features, Optional Chaining combined with Nullish Coalescing will certainly prove to be valuable additions.

Both Optional Chaining and Nullish Coalescing proposals are currently at Stage 4 and are available in most modern browsers as well as via the following babel plugins: @babel/plugin-proposal-optional-chaining and @babel/plugin-proposal-nullish-coalescing-operator.

Benefits of JavaScript Generators

JavaScript Symbols

One of the more nuanced features introduced in ES6 is that of Generator functions. Generators offer a powerful, yet often misunderstood mechanism for controlling the flow of operations, allowing developers to implement solutions with improved readability and efficiency. This article briefly delves into a few of the benefits that JavaScript Generators have to offer, elucidating on their purpose, functionality, and specific scenarios which can benefit from their usage.

A Generator function is a special type of function that can pause execution and subsequently resume at a later time, making it quite valuable for handling asynchronous operations as well as many other use cases. Unlike regular functions which run to completion upon invocation, Generator functions return an Iterator through which their execution can be controlled. It is important to note that while generators facilitate asynchronous operations, they do so by yielding Promises and require external mechanisms, such as async/await or libraries, to handle the asynchronous resolution.

Generators are defined with the function keyword followed by an asterisk (*); i.e. (function*), and are instantiated when called, but not executed immediately. Rather, they wait for the caller to request the next result. This is achieved using the Iterator.next() method, which resumes execution until the next yield statement is encountered, or the generator function returns.

As mentioned, Generator functions return an Iterator, therefore, all functionality of Iterables are available to them, such as for...of loops, destructuring, ...rest parameters, etc.:

Generators allow for the creation of custom iteration logic, such as generating sequences without the need to pre-calculate the entire set. For example, one can generate a Fibonacci sequence using generators as follows:

Generators have the ability to maintain state between yields, thus they are quite useful for managing stateful iterations. This feature can be leveraged in scenarios such as those which require pause and resume logic based on runtime conditions. For instance:

It may initially seem confusing as to how the value passed to game.next(value) is referenced within the Generator function. However, it is important to understand how this mechanism works as it is a core feature of generators, allowing them to interact dynamically with external input. Below is a breakdown outlining this behavior in the context of the above example:

  1. Starting the Generator: When game.next() is first called, the gameState generator function begins execution until it reaches the first yield statement. This initial call starts the generator but does not yet pass any value into it, as the generator is not yet paused at a yield that could receive a value.
  2. Pausing Execution: The yield statement pauses the generator’s execution and waits for the next input to be provided. This pausing mechanism is what differentiates generators from regular functions, allowing for a two-way exchange of values.
  3. Resuming with a Value: After the generator is initiated and paused at a yield, calling game.next(value) resumes execution, passing the value into the generator. This passed value is received by the yield expression where the generator was paused.
  4. Processing and Pausing Again: Once the generator function receives the value and resumes execution, it processes operations following the yield until it either encounters the next yield (and pauses again, awaiting further input), reaches a return statement (effectively ending the generator’s execution), or completes its execution block.

This interactive capability of generators to receive external inputs and potentially alter their internal state or control flow based on those inputs is what makes them particularly powerful for tasks requiring stateful iterations or complex control flows.

In addition to yielding values with yield, generators have a distinct behavior when it comes to the return statement. A return statement inside a generator function does not merely exit the function, but instead, it provides a value that can be retrieved by the iterator. This behavior allows generators to signal a final value before ceasing their execution.

When a generator encounters a return statement, it returns an object with two properties: value, which is the value specified by the return statement, and done, which is set to true to indicate that the generator has completed its execution. This is different from the yield statement, which also returns an object but with done set to false until the generator function has fully completed.

This example illustrates that after the return statement is executed, the generator indicates it is done, and no further values can be yielded. However, the final value returned by the generator can be used to convey meaningful information or a result to the iterator, effectively providing a clean way to end the generator’s execution while also returning a value.

Generators also provide a return() method that can be used to terminate the generator’s execution prematurely. When return() is called on a generator object, the generator is immediately terminated and returns an object with a value property set to the argument provided to return(), and a done property set to true. This method is especially useful for allowing clients to cleanly exit generator functions, such as for ensuring resources are released appropriately, etc..

In this example, after the first yield is consumed, return() is invoked on the generator. This action terminates the generator, returns the provided value, and sets the done property of the generator to true, indicating that the generator has completed and will no longer yield values.

This capability of generators to be terminated early and cleanly, returning a specified value, provides developers fine-grained control over generator execution.

Generators provide a robust mechanism for error handling, allowing errors to be thrown back into the generator’s execution context. This is accomplished using the generator.throw() method. When an error is thrown within a generator, the current yield expression is replaced by a throw statement, causing the generator to resume execution. If the thrown error is not caught within the generator, it propagates back to the caller.

This feature is particularly useful for managing errors in asynchronous operations, enabling developers to handle errors in a synchronous-like manner within the asynchronous control flow of a generator.

This example illustrates how generator.throw() can be used to simulate error conditions and test error handling logic within generators. It also shows how generators maintain their state and control flow, even in the presence of errors, providing a powerful tool for asynchronous error management.

One particularly interesting feature of Generators is that they can be composed of other generators via the yield* operator.

The ability to compose Generators allows for implementing various levels of abstraction and reuse, making their usage much more flexible.

Generators can be used for many purposes, ranging from basic use-cases such as generating a sequence of numbers, to more complex scenarios such as handling streams of data so as to allow for processing input as it arrives. Through the brief examples above, we’ve seen how Generators can improve the way we, as developers, approach implementing solutions for asynchronous programming, iteration, and state management.

Quick Tip: React Spring & Babel Loader

Recently, I had integrated React Spring within an Application, and while it is one of the best Animation Libraries for React I have come across in quite some time; unfortunately, I encountered some issues when running tests and production builds.

Essentially, the issues I experienced were related to the imported modules being written in ES6. This was an issue for me as I prefer to have webpack babel-loader configured to exclude node_modules and only transpile project sources.

Fortunately, the work around for this is quite simple: just import the CommonJS modules (i.e. .cjs extensions) rather than their ES6 counterparts (i.e. no extension).

Thus, simply changing:

To:

Resolves the issue.

And so, should you happen to come across build issues when using React Spring, a nice alternative to including the node_modules directory or specific dependencies is to simply import the CommonJS modules.

Unique Identifiers with JavaScript Symbols

JavaScript Symbols

The introduction of Symbols in ES6 marked a significant milestone, offering developers a new primitive type to enhance code clarity, privacy, and interoperability.

At their core, Symbols serve as unique, immutable identifiers, making them quite valuable for many use-cases. This article delves into the benefits of JavaScript Symbols, illustrating how they can be leveraged to provide implementations which are more secure and mitigate the risk of unforeseen conflicts.

Before we explore the benefits of Symbols, it’s important to first understand what the actually are. In JavaScript, a Symbol is a primitive data type, just like string, number, boolean, etc.. However, what sets Symbols apart is their guarantee of uniqueness. Every time you create a Symbol, it is distinct from all other Symbols, even if they share the same value.

Creating a Symbol is rather straightforward:

Despite having the same value, name1 and name2 are not equal.

There are numerous benefits to using Symbols, especially when using them within Objects.

Ensuring Property Uniqueness:
One of the most prominent benefits of Symbols is their role in ensuring property uniqueness within objects. This uniqueness is particularly beneficial in avoiding property name collisions, especially when working with complex implementations or when integrating third-party libraries.

Symbol Properties are Not Enumerated:
Another advantage of Symbols is that properties keyed by Symbols are not enumerated in for...in, or Object.keys(), Object.values(), or Object.entries(). This characteristic can be used to hide certain properties from the enumeration process, thus providing a form of property privacy.

Facilitating Meta-Programming:
Symbols play a pivotal role in JavaScript’s meta-programming capabilities. Several well-known Symbols, are used to customize the behavior of certain language constructs. For example, Symbol.iterator allows an object to define its iteration behavior, enabling it to be compatible with both the for...of loop and spread operator.

Enhanced Debugging:
Symbols can also aid in debugging by providing a descriptive identifier for otherwise anonymous properties. When you create a Symbol with a Symbol description, this description is shown in debugging tools, making it easier to identify and differentiate between various Symbols.

JavaScript Symbols present a robust mechanism for ensuring uniqueness, enhancing privacy, and empowering meta-programming within applications. By leveraging Symbols, developers can avoid common pitfalls such as property name collisions and inadvertently exposing internal properties, leading to more secure, maintainable, and sophisticated deigns. As JavaScript continues to evolve, understanding and utilizing Symbols will undoubtedly become an essential skill for modern web developers.

React PropTypes and ES6 Destructuring

At times one may be justified in the argument that cognitive (over)load is just an expected part of the overall developer experience. Fortunately, there are numerous steps we can take to minimize the general noise which tends to distract our intended focus. One particularly simple – yet effective – example is to remove unnecessary redundancy wherever possible. In doing so, we afford both our peers and ourselves a codebase which, over time, becomes considerably easier to maintain.

For instance, when performing code reviews, more often than not I tend to see considerable redundancy when specifying React PropTypes. Typically, something along the lines of:

As can be seen, with each new prop we are redundantly referencing React PropType lookup paths. And, while the ideal components will have a limited number of props (either connected directly, or passed down), the redundancy still remains for any component which references the same prop type. Considering the number of components a given application may contain, we can rightfully assume that the above redundancy will grow proportionally.

With the above in mind, we can easily reduce the redundancy (as well as micro-optimize the lookup paths) be simply destructuring the props of interest as follows:

While I would consider the above to be simplified enough; one could also take this a step further and destructure the isRequired props, which, in some circumstances, may be useful as well:

Admittedly, this example is rather straight-forward; however, it does help to emphasize the point that only through consistent vigilance can we ensure our source will continue to evolve organically while remaining as simple as possible.