39 postagens marcadas com "ECMAScript"

A proposta de Gerenciamento Explícito de Recursos introduz uma abordagem determinística para gerenciar explicitamente o ciclo de vida de recursos como manipuladores de arquivos, conexões de rede e mais. Esta proposta traz as seguintes adições à linguagem: as declarações using e await using, que chamam automaticamente o método dispose quando um recurso sai do escopo; os símbolos [Symbol.dispose]() e [Symbol.asyncDispose]() para operações de limpeza; dois novos objetos globais DisposableStack e AsyncDisposableStack como contêineres para agregar recursos descartáveis; e SuppressedError como um novo tipo de erro (contém tanto o erro que foi lançado mais recentemente, quanto o erro que foi suprimido) para lidar com o cenário onde um erro ocorre durante o descarte de um recurso, potencialmente mascarando um erro existente lançado pelo corpo ou pelo descarte de outro recurso. Essas adições permitem que os desenvolvedores escrevam códigos mais robustos, performáticos e mantíveis, fornecendo controle granular sobre o descarte de recursos.

Ajuda para iteradores são uma coleção de novos métodos no protótipo Iterator que ajudam no uso geral de iteradores. Como esses métodos auxiliares estão no protótipo do iterador, qualquer objeto que tenha Iterator.prototype em sua cadeia de protótipos (por exemplo, iteradores de arrays) terá os métodos. Nas seções a seguir, explicamos as ajudas para iteradores. Todos os exemplos fornecidos funcionam em uma página de arquivo de blog que inclui uma lista de artigos de blog, ilustrando como as ajudas de iterador são úteis para encontrar e manipular postagens. Você pode testá-los na página do blog do V8!

Anteriormente​

O V8 lançou o recurso import assertions na versão v9.1. Este recurso permitiu que declarações de importação de módulos incluíssem informações adicionais usando a palavra-chave assert. Essas informações adicionais atualmente são usadas para importar módulos JSON e CSS dentro de módulos JavaScript.

JavaScript suporta expressões regulares desde o ECMAScript 3 (1999). Dezesseis anos depois, o ES2015 introduziu modo Unicode (a flag u), modo sticky (a flag y), e o getter RegExp.prototype.flags. Três anos depois, o ES2018 introduziu modo dotAll (a flag s), afirmações lookbehind, grupos de captura nomeados, e escapes de propriedades de caracteres Unicode. E no ES2020, String.prototype.matchAll tornou mais fácil trabalhar com expressões regulares. As expressões regulares do JavaScript evoluíram bastante e continuam melhorando.

Encontrando elementos desde o início​

Encontrar um elemento que satisfaça alguma condição em um Array é uma tarefa comum e é feita com os métodos find e findIndex em Array.prototype e nos vários protótipos de TypedArray. Array.prototype.find recebe um predicado e retorna o primeiro elemento no array para o qual o predicado retorna true. Se o predicado não retornar true para nenhum elemento, o método retorna undefined.

O novo método at em Array.prototype, nos diversos protótipos de TypedArray e em String.prototype torna mais fácil e conciso acessar um elemento próximo ao final da coleção.

Acessar o N-ésimo elemento a partir do final de uma coleção é uma operação comum. No entanto, as formas usuais de fazê-lo são verbosas, como my_array[my_array.length - N], ou podem não ser performáticas, como my_array.slice(-N)[0]. O novo método at torna essa operação mais ergonômica ao interpretar índices negativos como significando "a partir do final". Os exemplos anteriores podem ser expressos como my_array.at(-N).

Imagine que você tem uma função que chama dois processos de trabalho separados doSomeWork e doMoreWork. Ambas as funções podem lançar o mesmo tipo de erros, mas você precisa tratá-los de maneiras diferentes.

Capturar o erro e lançá-lo novamente com informações contextuais adicionais é uma abordagem comum para esse problema, por exemplo:

function doWork() {
  try {
    doSomeWork();
  } catch (err) {
    throw new CustomError('Falha em algum trabalho', err);
  }
  doMoreWork();
}

try {
  doWork();
} catch (err) {
  // O |err| vem de |doSomeWork| ou de |doMoreWork|?
}

Infelizmente, a solução acima é trabalhosa, já que é necessário criar seu próprio CustomError. E, pior ainda, nenhuma ferramenta de desenvolvimento é capaz de fornecer mensagens de diagnóstico úteis para exceções inesperadas, pois não há consenso sobre como representar adequadamente esses erros.

Hoje, é muito comum escrever código assim:

const hasOwnProperty = Object.prototype.hasOwnProperty;

if (hasOwnProperty.call(object, 'foo')) {
  // `object` possui a propriedade `foo`.
}

Ou usar bibliotecas que expõem uma versão simplificada de Object.prototype.hasOwnProperty, como has ou lodash.has.

Com a proposta Object.hasOwn, podemos simplesmente escrever:

if (Object.hasOwn(object, 'foo')) {
  // `object` possui a propriedade `foo`.
}

Object.hasOwn já está disponível no V8 v9.3 por trás da flag --harmony-object-has-own, e em breve será implementado no Chrome.

Suporte para Object.hasOwn​

O novo recurso de declarações de importação permite que instruções de importação de módulos incluam informações adicionais junto ao especificador do módulo. Um uso inicial para o recurso é permitir que documentos JSON sejam importados como módulos JSON:

O operador in pode ser usado para testar se o objeto dado (ou qualquer objeto em sua cadeia de protótipos) possui a propriedade dada:

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

O recurso de verificações de marca privada estende o operador in para suportar campos de classe privados:

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; não é o mesmo #foo

Como os nomes privados estão disponíveis apenas dentro da classe que os define, o teste também deve ocorrer dentro da classe, por exemplo, em um método como static test acima.

As instâncias de subclasses recebem campos privados da classe pai como propriedades próprias:

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

Mas objetos criados com Object.create (ou que têm o protótipo definido posteriormente via o setter __proto__ ou Object.setPrototypeOf) não recebem os campos privados como propriedades próprias. Como a busca de campos privados funciona apenas em propriedades próprias, o operador in não encontra esses campos herdados: