¿Futuras características de JS?!

Hola, JS Nation. Bienvenidos a las futuras características de JavaScript. En esta charla, vamos a repasar diferentes propuestas desde la etapa 0 hasta la etapa 3, entender por qué existen, qué están tratando de resolver, y esperamos, que se implementen en todos los entornos de JavaScript.

Soy Hemant. Soy un Gerente de Ingeniería aquí en PayPal, un delegado de TC39, un experto desarrollador de Google para el Dominio Web y Pagos. Puedes encontrarme en Newman en Twitter o buscarme en html.com. ECMA International tiene muchas comunidades técnicas, de las cuales TC39 resulta ser la comunidad de ECMAScript, que es responsable de la especificación que JavaScript implementa. El proceso de TC39 incluye diferentes etapas, comenzando desde la Etapa 0 hasta la Etapa 4, donde la Etapa 4 está terminada e implementada en diferentes entornos, y la Etapa 1 es más como un hombre de paja con solo una idea básica de lo que es la propuesta. En esta charla, vamos desde la Etapa 0 hasta la Etapa 3 y vemos diferentes propuestas.

Si observamos el estado actual de cómo están las propuestas, en la Etapa 0, tenemos 18 propuestas. En la Etapa 1 tenemos 91 propuestas, y en la Etapa 2 tenemos 22, y en la Etapa 3 tenemos 17, y en la Etapa 4 tenemos 59 propuestas. Vamos a sumergirnos y sorprendernos con algunas de estas propuestas, comenzando con la Etapa 3.

Supongamos que tenemos un array de objetos y quieres encontrar un valor particular desde el final de el array. ¿Qué harías? Probablemente harías un reverse en ese array y luego un find. En este caso estamos tratando de encontrar los valores que no son divisibles por 2. Y en este caso obtuvimos el valor 3, pero tuvimos que invertir el array y luego hacer un find. ¿Qué tal si tuviéramos un método conveniente que dijera, array.findFromLast, array.findLast, aquí está la condición, dame el elemento. ¿Y si quisieras encontrar el último índice? De nuevo harías un reverse y harías un find.index, y tomarías el array.length y restarías menos 1 de él y restarías ese valor de lo que encontramos si el resultado coincide para encontrar el índice. En este caso el valor era 2. Supongamos que la condición no se cumple, donde estamos buscando el número 42. El valor debería haber sido menos 1, pero es 4. ¿Qué tal si tuviéramos un método que dijera, array.findLastIndex, y cuando se cumple la condición encontrará el índice si está presente, y si no, daría menos 1. ¿No sería conveniente? Aquí a la izquierda hay un comentario de uno de los problemas en GitHub para esta propuesta donde la idea era discutir y llegar a nombres. Como puedes ver, algunos de los nombres que surgieron en el problema eran como findRight, findIndexRight, findLast, findIndexLast, findEnd, findIndexEnd, y así sucesivamente. Finalmente tenemos findLast, y last, findLastIndex como la propuesta hoy. En el lado derecho podemos ver una implementación de la fuente de Chromium que dice fastArray findLast. Si quieres abrir la especificación, podrías hacer un mapeo uno a uno para cada una de esas líneas en este código para entender cómo se implementa la especificación. Por ejemplo, en el comentario donde dice 4, ese es el punto cuatro en la especificación que dice que k sea length menos uno, y ahí es donde tenemos la implementación exacta aquí. Eso es findLast y findLastIndex. Luego tenemos import assertion.

Este tipo de propuesta ofrece una forma de afirmar el tipo que estamos importando. Por ejemplo, en este caso, estamos diciendo importar json de foo.json, afirmar tipo json. Estamos diciendo que esto es de tipo json, y si fueras a usar importaciones dinámicas, dirías importar foo.json y decir afirmar tipo json cuando estás haciendo una importación dinámica, y si dices que tienes un JavaScript que está exportando un valor y quieres exportar ese valor desde tu archivo, podríamos decir exportar valor de foo.js que está exportando ese valor y luego estás afirmando que el tipo es JavaScript.

Y finalmente, podrías usar el tipo para ser WebAssembly y esto también puede ser usado en la etiqueta de script. Y podrías estar preguntándote por qué debería usar un tipo de afirmación? ¿Por qué necesito esto en línea? ¿Por qué no simplemente importar JSON de foo.json? Bueno, resulta que simplemente confiar en el tipo MIME para averiguar si es JSON o no causa un error de seguridad. Hay muchas preocupaciones en torno a la seguridad al importar un archivo aleatorio. Y luego tienes que asegurarte de que estás afirmando que esto es de tipo JSON y si es algo más, aparte de JSON, lanzaría un error y diría, hey, no lo sé porque estoy tratando de afirmar que esto es un archivo JSON y no lo es, manteniendo así el código más seguro y dándonos una forma fácil de expresarnos en línea sobre qué tipo es esto en términos de afirmar que esto es lo que realmente estamos importando.

De manera similar, tenemos módulos JSON, que son muy similares a lo que vimos anteriormente, puedes importar JSON como módulos y tener este tipo de afirmación. Pero podrías estar preguntándote por qué dos propuestas diferentes? ¿Es muy similar a lo que acabamos de ver anteriormente? Bueno, si te adentras en las notas de la reunión, puedes notar aquí que hubo una discusión y la decisión que se tomó decía, una de las decisiones fue que desacoplar los módulos JSON, para que eso pase a la etapa dos, y luego avance a diferentes estados, ¿verdad? Esto es algo común que sucede durante la fase de una propuesta, puede ser modificada, cambia, puede ramificarse en dos propuestas diferentes, también puede ser descartada y rechazada por muchas razones. Así que aquí vimos que el módulo JSON formaba parte de la afirmación de importación, pero se convirtió en una propuesta independiente en sí misma para que pueda acelerarse rápidamente hacia el final. Definitivamente no te pierdas esta charla de Julia, que es parte de GSNation esta vez y ella está hablando de cómo funcionan los módulos JS desde la perspectiva de un navegador. Ella es delegada del 39 por supuesto y como implementadora en Firefox, esta charla es imprescindible si quieres saber más sobre cómo funcionan los módulos JSON.

La otra propuesta que tenemos es Cambiar Array por Copia. Como dice el nombre, estás cambiando un array por copia. Veamos algunos de los ejemplos aquí. Supongamos que tienes una secuencia, un array que es uno, dos, tres y luego dices dos invertidos, por supuesto obtienes tres a uno, pero curiosamente, la secuencia permanece igual. No estamos mutando la secuencia y eso es súper útil cuando no estás mutando el array pero aún así obtienes la inversa del array.

De manera similar tienes ordenar, dos ordenados, donde quieres ordenar, digamos en este caso, quieres Y podrías decir fuera de orden dos ordenados, obtienes el array ordenado pero el array original permanece igual. Y tenemos el método bit donde si quieres hacer un cambio en el array. En este caso, la corrección necesaria es el array donde tenemos uno, uno y tres y queremos tener 42 en el índice uno en lugar de uno. Así que decimos corrección necesaria con 142, obtenemos 142, tres, pero el array original permanece igual, eso es uno, uno, tres.

Supongamos que quieres empalmar. También podrías llamar a los dos empalmados. Aquí tenemos dos en dos así que obtenemos 5, 4, 1, 0 de un array que era 5, 4, 3, 2, 1, 0. Así que lo empalmamos pero el array original de entrada permanece igual y no se cambia. Este es un método muy conveniente. Tenemos array groupby y array groupby para map. Digamos que tenemos un inventario con verduras y frutas. En este ejemplo, con diferentes cantidades. Entonces podrías simplemente decir inventario.group por tipo y obtienes un objeto que tiene las claves como fruta y verduras y los valores son array de los respectivos valores del inventario. Luego tenemos inventario.groupby para map que hace algo muy similar a lo que groupby abordó pero devuelve como un map. Así que podemos hacer todas las operaciones de map en el valor de retorno a diferencia de como inventario.groupby te da un objeto, aquí obtienes un map. Así que esto es por conveniencia para que puedas hacer todas las operaciones de map. Y esto tiene muchos casos de uso y es súper útil.

A continuación, tenemos la etapa dos. Supongamos que tenemos un generador que produce múltiplos de dos. Y, si quisieras convertir eso en un array, ¿qué harías? Hoy tomarías un array y usarías una sintaxis de for of await y la usarías en el generador y seguirías empujándolo al array y luego probablemente obtendrías un array. Así que básicamente convirtiendo eso en un array. ¿Y si tuviéramos un método fácil? Array from async. Le das un generador asíncrono, esperas en él y lo que obtienes de vuelta es un array. ¿No haría la vida más fácil con solo esta línea, que es súper conveniente? Y sí, si estás pensando en promesas, bueno, podríamos hacer lo mismo que hicimos en el ejemplo anterior. Si tu generador está produciendo promesas y luego quieres convertir eso en un array de promesas, entonces podrías simplemente decir async from array, generar promesas, esperar en ello y obtendrías un array.

Esto facilita mucho la vida si estás intentando trabajar con generadores y operadores asíncronos e intentando convertirlos en un array. Por lo tanto, es asíncrono desde un array. Es muy similar a un array.from donde podrías pasar un objeto que es como un array y convertirlo en un array si le das una longitud. Y de manera similar, es una extensión de eso que dice array from async en lugar de solo array from y pasarle un objeto.

La siguiente propuesta que tenemos son las expresiones de lanzamiento. Digamos que tenemos una función que dice guardar, y está recibiendo un parámetro. ¿Y si el usuario no pasa un parámetro o si el usuario pasa un parámetro que no quieres que pasen? Probablemente verificarías el tipo y harías todas las afirmaciones necesarias y luego lanzarías si no coincide con tu expectativa. ¿Y si esto se pudiera hacer como una expresión en línea? En este caso, dices que el nombre del archivo es igual a lanzar un nuevo error de tipo error argumento requerido. Esto lanzaría automáticamente si ese argumento no se pasa a la función guardar. Correcto. También podrías tenerlo dentro de los cuerpos de la función de error. En este caso, tienes una sintaxis libre de AST de extracción que tiene un método de ancho como una de sus claves. Si alguien está intentando usar el método de ancho, entonces podrías simplemente lanzar diciendo que evita usar el método de ancho en las declaraciones. Correcto. Entonces también puedes usarlo en operadores lógicos. Digamos que tienes un getter y un setter dentro de la clase. Y para el setter, dirías que si no se pasa el valor, entonces podrías lanzar diciendo que el valor es inválido. Correcto. Si no es el valor que estás buscando. Y también podrías usarlo en expresiones condicionales. Y si todas tus expresiones condicionales se agotan, puedes simplemente lanzar en cualquier lugar o decir que la codificación no es soportada. En este caso, tienes los diferentes codificadores desde el uso del deber de a hasta el de so on. Eso son las expresiones de lanzamiento.

Los Records y TPUs son una de las propuestas más importantes e interesantes de los últimos tiempos, que aportan inmutabilidad a JavaScript. Todos sabemos que cuando hacemos igualdades estrictas de dos objetos con los mismos pares de valores clave. Son falsos. Lo mismo ocurre con otros con los mismos valores. Pero si hacemos una igualdad estricta, nos dice que es falso. Pero si tienes esta sintaxis en la que tienes un hash seguido de una R, para lo que parece un objeto, y un hash seguido de lo que parece un array. Ambos se equiparan a sí mismos como verdaderos. Y eso es de acuerdo con el campo donde podrías decir tipo de hash, que parece un objeto, que es inmutable. Es un record. Y tipo de hash, que parece un array, que es inmutable. De nuevo, es un TPU. Así que si tienes un objeto, que quieres convertir en un record, podrías simplemente llamar al constructor de record y obtendrías el record de vuelta. O si tienes un array, que quieres convertir en TPU, podrías usar TPU from, pasarle un array y obtendrías un TPU de vuelta, y definitivamente debes ver la masterclass de Robin Richard sobre records y TPUs como estructuras de datos inmutables en JavaScript, donde profundiza en detalle. También es un delegado de TC39. Y esto es parte de la serie de masterclasses de JS Nation, también.

A continuación, tenemos el operador de tubería. Digamos, tenemos este ejemplo, que es Funzal registrando chalk.dim, object.keys del entorno variables, mapeando o variables de entorno y tomando los pares de valores clave y uniéndolos. Finalmente, uniendo todo el arco para crear una salida. ¿No es un poco confuso? Como, veamos cómo el cerebro probablemente intentaría evaluar esto. Diría object.keys desde el lado izquierdo, luego tenemos map en el lado derecho y tenemos join en el lado derecho. Y la plantilla en ambos lados, los caracteres de tilde y luego tenemos chalk.dim y luego tenemos Funzal log. Hay mucho anidamiento y código enrevesado. ¿Y si lo hiciéramos más fácil? ¿Verdad? Veamos este ejemplo, donde solo son object.keys de variables de entorno, mapea las variables de entorno, devuélveme esta cadena, y luego únelas. Y luego tienes esta extraña sintaxis, que dice tubería y luego dice dólar-dólar porcentaje donde el porcentaje básicamente es el valor que se evaluó en el paso anterior. Luego decimos chalk.dim porcentaje. De nuevo, ese porcentaje es reemplazado por el valor que se evaluó en el anterior paso. Y finalmente, hacemos console.log porcentaje. Ese es el valor que se evaluó en el paso anterior. Facilitando así su lectura y comprensión, también para cambiar diferentes métodos. Y ese es un operador de tubería. Hay dos propuestas competidoras para los operadores de tubería, hack y fsharp tuberías. Pero había otra propuesta, que era una mezcla inteligente de estas dos propuestas. Pero esa ha sido retirada. Esto es lo que tenemos actualmente hoy para el operador de tubería.

Map.implace es otra propuesta interesante donde, digamos, tienes un mapa y quieres verificar si la clave existe dentro del mapa o no antes de establecerla, que es un caso de uso común, ¿verdad? Dirías, si noMap tieneKey, entonces map.setKeyValue, luego haces map.get y haces cosas. ¿Y si pudiera ser más simple? Y dices, map.implaceKey, inserta, valor, haz, haz esa cosa. ¿Verdad? Básicamente verificaría si eso está ahí o no y luego insertaría. Y probablemente también habría hecho esto. map.get obtiene el valor antiguo. Si el valor antiguo no está ahí, entonces establece el valor y establece el valor actualizado. ¿Y si pudiéramos evitar estas dos búsquedas y hacerlo más simple? Podrías hacer map.implace y poner a, has puesto una clave allí y tienes métodos de actualización e inserción dentro de implace y podrías operar en base a tu caso de uso y map.implace hace más simple al evitar esas búsquedas extras.

IteratorHelper es una gran propuesta y permíteme intentar ajustarla en esta diapositiva y ver las diferentes cosas que proporciona IteratorHelper. ¿Correcto? Digamos que tienes una función, que es una función generadora, que de alguna manera genera todos los números naturales y, por supuesto, harías result.next, seguirías obteniendo esos números. ¿Y si quisieras hacer un map en este iterador? Sí. Esta propuesta habla de ello. Podrías hacer un map. ¿Quieres hacer un filtro? Sí, podríamos hacer un filtro. Y aquí tienes un ejemplo, tienes un iterador asíncrono de URLs, obtienes un iterador asíncrono, luego haces un map en él, luego haces un await fetch y luego obtienes la respuesta JSON y finalmente haces un two array para que tengas un array de todas esas respuestas como JSONs, ¿verdad? Y luego quieres hacer un take, si quieres ser un poco perezoso, y solo tomar solo tres de ellos de esa enorme serie que este generador está proporcionando, podrías hacer eso. Si quieres descartar tres, podrías hacer eso. Si quieres tener un, si haces dot values, obtienes ese iterador y quieres hacerlo como pares de índices, entonces obtienes un par de índices, eso sería como un cero x y un uno y y un dos z y así sucesivamente. Bien, y luego también podrías hacer un for each, every, some, find, todo esto en valor, así que eso es Iterator helper, donde hace la vida más fácil para iterar sobre todos estos diferentes métodos y tener un iterador asíncrono. Ahora estamos en la primera etapa.

Digamos que tienes un array de a, b, c, d y quieres hacer array.slice uno, tres. ¿Qué obtenemos? ¿Es b, c, o b, c, d? Digamos que tenemos un array de a, b, c, d de nuevo, y hacemos array.slice. ¿Qué obtenemos? a, b, c, o d, ¿verdad? Bueno, esto puede ser más fácil con la notación de corte, que es un poco intuitiva, donde dices, array 3 dos puntos, eso significa dame d, y si digo 1 dos puntos 3, eso es b, c, dame b, c. Si array de menos 2, empieza desde el final, dame a, b. Array de menos 10, que está fuera de límites, dame un array vacío. Así que si vienes del mundo de Python, probablemente habrías usado esto mucho, y muchos otros lenguajes proporcionan esta facilidad, y sería muy bueno ver esto en JavaScript.

La anotación de tipo es una gran propuesta y ha generado mucho ruido en el dominio público, y a muchas personas les interesa debido a cómo la gente está acostumbrada a usar TypeScript estos días en términos de uso de tipo. Aquí está de qué trata básicamente la propuesta. Si estás acostumbrado a JS doc, probablemente hayas usado algo como esto, donde dijiste, hey, aquí está mi función de string, string, string, directamente desde la lectura de la propuesta, donde tenemos p1 como un parámetro, que es un string, y p2 es un string, y así sucesivamente. Y así es probablemente como lo pondrías en tu JS doc. Y con esta propuesta, se parece mucho a la sintaxis de TypeScript aquí, donde dirías que p1 es un string, p2 es opcional, donde es un string, y p2, p3 es opcional en string, y p4 se está predeterminando a test. ¿Y esta función devuelve un string, verdad? Así que la anotación de tipo nos da este tipo de sintaxis donde podrías agregar las anotaciones a tus métodos. Y es una propuesta en evolución, y es muy interesante leer sobre los detalles.

A continuación, tenemos array UNIQBY. Como dice el nombre, supongamos que tienes un array de, en este caso, tenemos 1, 2, 3, 3, 2, 1, y hacemos un UNIQBY, obtenemos 1, 2, 3. Pero se pone interesante si el array tiene objetos, ¿verdad? Y quieres hacer UNIQBY UID, entonces podrías hacerlo. O quieres hacer un UNIQBY que toma un ID UID, quieres hacer esos pares y probablemente obtener UNIQBY, también podrías conseguirlo. Podrías conseguirlo también. Así que UNIQBY es un método muy conveniente para obtener valores únicos de un array que tiene duplicados.

El rango de números y big int es una propuesta que de alguna manera proporciona este método de rango en big int y números. Vea en el primer ejemplo, tenemos un bucle lejano donde el rango de big int comienza desde 0 hasta 43N, que de alguna manera bloquea los números de 0 a 42N. Si te refieres al ayudante de iterador que vimos anteriormente, donde puedes hacer un rango de números de 0 a infinito, tomar digamos mil de ellos y filtrar los números que no son divisibles por 3 y luego hacer un 2-array, obtendrías esos números.

O digamos que tienes un generador que genera solo números pares de 0 a infinito y solo quieres números de, como obtener todos los números impares de digamos 1 a 99. Podrías hacer un rango de números de 1 a 100 de 2, entonces obtendrías esos. Así que ese es el método de rango en número y rango de big int.

La Función 1 es otra propuesta interesante. Supongamos que tienes una función que quieres ejecutar solo una vez por varias razones, y luego, en este ejemplo, dices una función una vez y dices F.1's como F1's y F1's de 3 imprimiría 3 y devolvería 6. Ese es el console log que está en la función. Pero F, de nuevo, si llamas a la misma función, F1's con 3, no imprime nada pero devuelve 6. F1's de 2, también devuelve 6, no imprime nada, ¿verdad? Así que solo se ejecuta una vez y si sigues ejecutándolo, de nuevo, solo obtienes el mismo valor que se evaluó cuando se invocó por primera vez. Hay algunas discusiones interesantes en el problema para la función 1. Supongamos que tienes una función que es un code recursivo y haces un G.once, y luego llamas a G una vez, ¿qué debería pasar? O supongamos que tienes una función, g de x, que hace cosas que llevan mucho tiempo y tiene operaciones asíncronas en ella. Luego dices, async G una vez y obtienes promesa 1 y haces async G una vez más, obtienes una promesa 2, ¿qué debería pasar? Así que estas son algunas de las discusiones interesantes que ocurren en la propuesta y es una buena práctica ir y leer los problemas e intentar entender qué está pasando y también podríamos contribuir con tus opiniones. String.cook es otra propuesta interesante donde supongamos que tienes una secuencia unicode aquí para, digamos, u61, haces string.raw, obtienes lo mismo de vuelta. Haces un string.raw y luego pasas un objeto que tiene una clave raw y que tiene un array de valor de eso, la secuencia unicode, obtendrías una A. Así que si haces un console log, probablemente obtendrías A para esta secuencia unicode. ¿Qué pasaría si tuviéramos string.cook en lugar de decir string.raw pasando un objeto que tiene raw como su clave y el valor siendo un array con ese valor que quieres convertir en una cadena, bueno, es complejo, ¿verdad? A veces podrías perder que hay esta propiedad con string. Que se comporta de una manera si pasas un objeto con raw como su clave. Más bien, si tuvieras string.cook y solo pasaras slash u61, obtendrías A. Así que esta propuesta lo simplifica y hace que tu code sea menos propenso a errores mientras estás operando con string.raw. DoExpression es una propuesta que simplifica las cosas al evaluar y asignar valores a, digamos, valores de retorno o a variables. En este ejemplo, es un ejemplo JSX donde tienes una doExpression que dice si estás conectado, entonces devuelve un botón de desconexión. Si no, devuelves un botón de conexión. Este es un constructo bastante común en JSX, ¿verdad? Probablemente usarías un operador de condición o intentarías devolver este componente aquí. Solo estamos poniendo una doExpression que evalúa lo que sea que esté escrito, lo que se evalúa como verdadero es el valor que se devuelve. Veamos otro ejemplo simple aquí. Supongamos que tenemos let x en una doExpression, y decimos que temp es la llamada a la función. Y luego decimos temp en temp más uno. Así que temp en temp más uno es lo que sea que se evalúe se asigna a la variable x. De manera similar, si tienes x do con else, else, else, cualquier condición que coincida y si se llama al método F o G o H, el valor de retorno de esos métodos se asigna a x. Haciéndolo más simple en términos de asignar los valores a las variables cuando hay un constructo anidado y hay demasiadas cosas para devolver y evaluar. En una línea similar, tenemos async doExpression. Supongamos que tenemos operaciones asíncronas dentro del bloque do. Así que podríamos decir async do y decir fetch a thing y devolver una respuesta JSON y fetch otra cosa, obtener una respuesta JSON, ponerla en promise.all y evaluar y obtener el resultado. El emparejamiento de patrones es otra propuesta interesante donde supongamos que estás obteniendo algún servicio JSON en el ejemplo y obtienes un resultado y haces un match en matchable y luego dices cuando digamos que mi estado es 404, podría decir JSON no encontrado o podría simplemente recoger el estado y hacer una comprobación yo mismo y decir si el estado es mayor que 400 entonces lanzar un error de solicitud y así sucesivamente. Y la aplicación parcial si estás en programación funcional entonces realmente sabrías lo que es una aplicación parcial, supongamos que tienes una función que toma n número de argumentos y estás pasando un número parcial de argumentos a ella en lugar de pasar todo y más tarde pasarías el otro argumento a medida que tu función avanza y en este ejemplo podrías hacer una aplicación parcial desde la izquierda o una aplicación parcial desde la derecha o podrías hacer una aplicación parcial de cualquier argumento correcto y ahí es donde entra en acción la aplicación parcial y el signo de interrogación es el marcador de posición que dice hey este argumento se pasará más tarde. Finalmente estamos en la etapa cero donde tenemos esta sintaxis de bind supongamos que tenemos objeto seguido por el doble dos puntos que es la sintaxis de bind y función que básicamente es igual a objeto dot función dot bind objeto supongamos que fueras a usar console log como una variable hace unos años en la historia probablemente harías un console dot log bind console para que el objeto esté vinculado al contexto correcto. De manera similar si tienes objeto seguido por esto sintaxis de bind función valor que es igual en función dot call objeto valor y si fueras a usar esta sintaxis de bind objeto dot función valor que es igual en decir que objeto dot función dot call objeto valor. Así que veamos un ejemplo rápido para hacerlo mucho más simple. Supongamos que tienes una biblioteca de iteradores que dice que te da map take while y for each y tenemos una función get player que te da todos los jugadores y estás mapeando a través de esos jugadores aunque no es mapeable haces un map dot call y luego obtienes los personajes luego haces un take while dot call y obtienes las fuerzas que son mayores que 100 y luego finalmente haces un for each dot call para recorrerlos y console log. Hubiera sido más simple usar esto sintaxis de bind dirías get player esto bind syntax map it with x dot characters bind it with take while again get the strength y hacer un for each así que todo está correctamente vinculado el contexto de ejecución y obtienes el valor que estás esperando. El último que tenemos es string characters supongamos que tenemos una cadena con un guión bajo guión abc guión bajo guión y los caracteres que tenemos es un guión bajo podríamos decir string dot trim characters eso encontraría todos esos caracteres para recortarlo así que solo tenemos abc y luego podríamos hacer un string dot trim characters podrías hacer un trim start eso solo haría ya sabes recortar los caracteres al principio así que el guión bajo guión se ha ido y lo que tenemos es abc underscore abc guión bajo guión y si lo haces desde el final el guión bajo guión desde el final se recorta así que eso es recortar caracteres de cadena eso es todo lo que tenemos amigos y espero que les hayan gustado todas las propuestas y estoy super emocionado por estas propuestas y espero que todas ellas lleguen a diferentes entornos de JavaScript y cosechemos los beneficios de ello. Gracias.