39 posts tagged with "ECMAScript"

The Explicit Resource Management proposal introduces a deterministic approach to explicitly manage the lifecycle of resources like file handles, network connections, and more. This proposal brings the following additions to the language: the using and await using declarations, which automatically calls dispose method when a resource goes out of scope; [Symbol.dispose]() and [Symbol.asyncDispose]() symbols for cleanup operations; two new global objects DisposableStack and AsyncDisposableStack as containers to aggregate disposable resources; and SuppressedError as a new type of error (contain both the error that was most recently thrown, as well as the error that was suppressed) to address the scenario where an error occurs during the disposal of a resource, and potientially masking an existing error thrown from the body, or from the disposal of another resource. These additions enable developers to write more robust, performant, and maintainable code by providing fine-grained control over resource disposal.

Iterator helpers are a collection of new methods on Iterator prototype that help in general use of iterators. Since these helper methods are on the iterator prototype, any object that has Iterator.prototype on its prototype chain (e.g. array iterators) will get the methods. In the following subsections, we explain iterator helpers. All the provided examples are working in a blog archive page that includes list of blog posts, illustrating how iterator helpers are helpful for finding and manupulating posts. You can try them on V8 blog page!

Previously​

V8 shipped the import assertions feature in v9.1. This feature allowed module import statements to include additional information by using the assert keyword. This additional information is currently used to import JSON and CSS modules inside JavaScript modules.

JavaScript has supported regular expressions since ECMAScript 3 (1999). Sixteen years later, ES2015 introduced Unicode mode (the u flag), sticky mode (the y flag), and the RegExp.prototype.flags getter. Another three years later, ES2018 introduced dotAll mode (the s flag), lookbehind assertions, named capture groups, and Unicode character property escapes. And in ES2020, String.prototype.matchAll made it easier to work with regular expressions. JavaScript regular expressions have come a long way, and are still improving.

Finding elements from the beginning​

Finding an element that satisfies some condition in an Array is a common task and is done with the find and findIndex methods on Array.prototype and the various TypedArray prototypes. Array.prototype.find takes a predicate and returns the first element in the array for which that predicate returns true. If the predicate doesn't return true for any element, the method returns undefined.

The new at method on Array.prototype, the various TypedArray prototypes, and String.prototype makes accessing an element nearer to the end of the collection easier and more succinct.

Accessing the Nth element from the end of a collection is a common operation. However, the usual ways to do so are verbose, like my_array[my_array.length - N], or might not be performant, like my_array.slice(-N)[0]. The new at method makes this operation more ergonomic by interpreting negative indices to mean "from the end". The previous examples may be expressed as my_array.at(-N).

Imagine you have a function that is calling two separate work loads doSomeWork and doMoreWork. Both functions can throw the same kind of errors, but you need to handle them in different ways.

Catching the error and throwing it with additional contextual information is a common approach to this problem, for example:

function doWork() {
  try {
    doSomeWork();
  } catch (err) {
    throw new CustomError('Some work failed', err);
  }
  doMoreWork();
}

try {
  doWork();
} catch (err) {
  // Is |err| coming from |doSomeWork| or |doMoreWork|?
}

Unfortunately the above solution is laborious, since one needs to create its own CustomError. And, even worse, no developer tool is capable of providing helpful diagnosing messages to unexpected exceptions, since there is no consensus on how to properly represent these errors.

Today, it is very common to write code like this:

const hasOwnProperty = Object.prototype.hasOwnProperty;

if (hasOwnProperty.call(object, 'foo')) {
  // `object` has property `foo`.
}

Or to use libraries that expose a simple version of Object.prototype.hasOwnProperty, such as has or lodash.has.

With the Object.hasOwn proposal, we can simply write:

if (Object.hasOwn(object, 'foo')) {
  // `object` has property `foo`.
}

Object.hasOwn is already available in V8 v9.3 behind the --harmony-object-has-own flag, and we’ll be rolling it out in Chrome soon.

Object.hasOwn support​

The new import assertions feature allows module import statements to include additional information alongside the module specifier. An initial use for the feature is to enable JSON documents to be imported as JSON modules:

The in operator can be used for testing whether the given object (or any object in its prototype chain) has the given property:

const o1 = {'foo': 0};
console.log('foo' in o1); // true
const o2 = {};
console.log('foo' in o2); // false
const o3 = Object.create(o1);
console.log('foo' in o3); // true

The private brand checks feature extends the in operator to support private class fields:

class A {
  static test(obj) {
    console.log(#foo in obj);
  }
  #foo = 0;
}

A.test(new A()); // true
A.test({}); // false

class B {
  #foo = 0;
}

A.test(new B()); // false; it's not the same #foo

Since private names are only available inside the class which defines them, the test must also occur inside the class, for example in a method like static test above.

Subclass instances receive private fields from the parent class as own-properties:

class SubA extends A {};
A.test(new SubA()); // true

But objects created with with Object.create (or that have the prototype set later via the __proto__ setter or Object.setPrototypeOf) don't receive the private fields as own-properties. Because private field lookup only works on own-properties, the in operator does not find these inherited fields: