39 publicaciones etiquetados con "ECMAScript"

La propuesta de Gestión Explícita de Recursos introduce un enfoque determinista para gestionar explícitamente el ciclo de vida de recursos como manejadores de archivos, conexiones de red y más. Esta propuesta aporta las siguientes adiciones al lenguaje: las declaraciones using y await using, que llaman automáticamente al método de eliminación cuando un recurso sale del ámbito; los símbolos [Symbol.dispose]() y [Symbol.asyncDispose]() para operaciones de limpieza; dos nuevos objetos globales DisposableStack y AsyncDisposableStack como contenedores para agrupar recursos eliminables; y SuppressedError como un nuevo tipo de error (que contiene tanto el error más recientemente lanzado como el error que fue suprimido) para abordar el escenario donde ocurre un error durante la eliminación de un recurso, que potencialmente puede enmascarar un error existente lanzado desde el cuerpo o desde la eliminación de otro recurso. Estas adiciones permiten a los desarrolladores escribir código más robusto, eficiente y mantenible al proporcionar un control detallado sobre la eliminación de recursos.

Los ayudantes de iterador son una colección de nuevos métodos en el prototipo de Iterator que facilitan el uso general de los iteradores. Dado que estos métodos de ayuda están en el prototipo de iterador, cualquier objeto que tenga Iterator.prototype en su cadena de prototipos (por ejemplo, iteradores de arrays) obtendrá los métodos. En las siguientes subsecciones, explicamos los ayudantes de iterador. Todos los ejemplos proporcionados funcionan en una página de archivo de blog que incluye una lista de publicaciones, ilustrando cómo los ayudantes de iterador son útiles para encontrar y manipular publicaciones. ¡Puedes probarlos en la página del blog de V8!

Previamente​

V8 lanzó la función de declaraciones de importación en la versión v9.1. Esta característica permitía que las declaraciones de importación de módulos incluyeran información adicional utilizando la palabra clave assert. Esta información adicional actualmente se utiliza para importar módulos JSON y CSS dentro de módulos JavaScript.

JavaScript ha soportado expresiones regulares desde ECMAScript 3 (1999). Dieciséis años después, ES2015 introdujo el modo Unicode (el flag u), el modo sticky (el flag y), y el getter RegExp.prototype.flags. Tres años más tarde, ES2018 introdujo el modo dotAll (el flag s), las aseveraciones lookbehind, los grupos de captura con nombre, y los escapes de propiedades de carácter Unicode. Y en ES2020, String.prototype.matchAll facilitó trabajar con expresiones regulares. Las expresiones regulares en JavaScript han recorrido un largo camino y siguen mejorando.

Encontrar elementos desde el principio​

Encontrar un elemento que cumpla alguna condición en un Array es una tarea común y se realiza con los métodos find y findIndex en Array.prototype y los diversos prototipos de TypedArray. Array.prototype.find toma un predicado y devuelve el primer elemento en el array para el cual ese predicado devuelve true. Si el predicado no devuelve true para ningún elemento, el método retorna undefined.

El nuevo método at en Array.prototype, los distintos prototipos de TypedArray y String.prototype facilita el acceso a un elemento más cercano al final de la colección y lo hace más conciso.

Acceder al elemento N desde el final de una colección es una operación común. Sin embargo, las formas habituales de hacerlo son verbosas, como my_array[my_array.length - N], o podrían no ser eficientes, como my_array.slice(-N)[0]. El nuevo método at hace que esta operación sea más ergonómica al interpretar índices negativos como "desde el final". Los ejemplos anteriores pueden expresarse como my_array.at(-N).

Imagina que tienes una función que llama a dos cargas de trabajo separadas doSomeWork y doMoreWork. Ambas funciones pueden lanzar el mismo tipo de errores, pero necesitas manejarlos de diferentes maneras.

Atrapar el error y lanzarlo con información adicional contextual es un enfoque común para este problema, por ejemplo:

function doWork() {
  try {
    doSomeWork();
  } catch (err) {
    throw new CustomError('Fallo en el trabajo', err);
  }
  doMoreWork();
}

try {
  doWork();
} catch (err) {
  // ¿Proviene |err| de |doSomeWork| o de |doMoreWork|?
}

Desafortunadamente, la solución anterior es laboriosa, ya que uno necesita crear su propio CustomError. Y, aún peor, ninguna herramienta de desarrollo es capaz de proporcionar mensajes de diagnóstico útiles para excepciones inesperadas, ya que no hay consenso sobre cómo representar correctamente estos errores.

Hoy en día, es muy común escribir código como este:

const hasOwnProperty = Object.prototype.hasOwnProperty;

if (hasOwnProperty.call(object, 'foo')) {
  // `object` tiene la propiedad `foo`.
}

O usar bibliotecas que exponen una versión simple de Object.prototype.hasOwnProperty, como has o lodash.has.

Con la propuesta Object.hasOwn, podemos simplemente escribir:

if (Object.hasOwn(object, 'foo')) {
  // `object` tiene la propiedad `foo`.
}

Object.hasOwn ya está disponible en V8 v9.3 detrás de la bandera --harmony-object-has-own, y lo desplegaremos pronto en Chrome.

Compatibilidad con Object.hasOwn​

La nueva función de aserciones de importación permite que las declaraciones de importación de módulos incluyan información adicional junto al especificador del módulo. Un uso inicial de esta función es habilitar la importación de documentos JSON como módulos JSON:

El operador in puede ser usado para comprobar si un objeto dado (o cualquier objeto en su cadena de prototipos) tiene la propiedad especificada:

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

La característica de verificaciones de marca privada extiende el operador in para soportar campos privados de clase:

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; no es el mismo #foo

Dado que los nombres privados solo están disponibles dentro de la clase que los define, la prueba también debe ocurrir dentro de la clase, por ejemplo, en un método como static test arriba.

Las instancias de subclases reciben campos privados de la clase padre como propiedades propias:

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

Pero los objetos creados con Object.create (o que tienen el prototipo configurado más tarde mediante el setter __proto__ o Object.setPrototypeOf) no reciben los campos privados como propiedades propias. Debido a que la búsqueda de campos privados solo funciona en propiedades propias, el operador in no encuentra estos campos heredados: