Me recuerda al uso de try? await fetch() en Swift pero dado que JS no soporta opcionales con Swift, carece de sentido porque como bien comentas la firma de la función se tiene que adaptar para seguir la convención de envolver el output en un array, cuando sería más lógico añadir enums o sealed classes simuladad a lo Kotlin a la especificación de JS para implementar el patrón Result-Catch.
Tu propuesta terminó no gustandome porque después tendría que a result validar el tipado que tiene si es exitoso o no, mientras que si devuelves dos sabes que uno es la data que podría ser null y error tener algo y si error null data tiene algo, sería igual que golang, con su manejo de errores, quedaria bien al final lo de golang, pero no manches eso es solo un patrón, podrías hacer una función que retorne dos valores y allí adentro solo hacer 1 vez el try catch, ni es necesario este cambio al core de nodejs porque solo es un patron de comportamiento
soy partidario del uso de la palabra "try" antes de usar ?= ya q me parece algo anti intuitivo. lo q propones tambien estaria interesante pero cae el asunto donde el parametro q recibe la funcion de error tiene q ser del estilo (xq no le se el nombre al patron) onClick={funcion} y tiene por entendido q recibira el evento onclick la funcion de error. pero tambien como manejas el tipado es engorroso ya q tienes q hacer algo de typeof y eso es un paso q se puede saltar teniendo dos variables separadas
es innecesario realmente, es obligar a malas implementaciones, no es necesario llenar de try/catch o cada nada validaciones de datos así, es bueno y siempre lo hago, es hacer un componente encargado de ejecutar y controlar las peticiones, con eso ya solo llamo en una linea corta, eso se encarga de todo y breve.
la verdad si ayuda la propuesta a simplificar las cosas, y mas con el tipdo que muchas veces se pierde al tener varios scopes, pero no me grada demaciado la sintaxis de ?=, ya tenemos suficientes operadores, la propuesta con el try expression me parece mas intuitivo. Siento que el uso de ternarias puede complicar las cosas por que las expresiones no siempre son sencillas o cortas y tener un : flotando por ahi no ayuda con eso, ademas de que te obliga a hacer una funcion para el handler cuando no siempre es necesaria (o eso entendi de tu propuesta) y no esta claro de donde sale el error, por ultimo, terminaria retornando un typeof | undefined la expresion asi que igual el value habria que validarlo por segunda vez el 100% de las veces aunque exista un handleError ya que la ejecucion no para ahi. el retorno de la tupla con el error primero para asegurar que manejes el error me parece mejor ya que el tipado seria un [error] | [null, typeof] que al evaluar si existe error y manejarlo te da campo libre para que por inferencia el caso contrario tengas libre usar el value, asi que aqui no el 100% de las veces habria que validar el value lo que ya es ganancia
Como el error lo tienes en una variable puedes tratar el error despues de una ejecució es decir que despues de la operación try ejecutamos algo que si o si debe ejecutarse y luego tratar el error. es muy recomendable tratar el error, no por nada es un error.
Sea cual sea la decisión que tome el tc39, no va a cambiar el código actual, ya que js es retrocompatible, si se añade una sintaxis simplificada no se está obligando su adopción inmediata y los que quieran utilizarla la posible nueva sintaxis pueden usarla
y que pasa si la función handleError tiene mas de un parámetro? como sabría el interprete cual es cual? para mi no tiene mucho sentido esta propuesta, la idea de manejar los errores con try y catch es poder centrarse primero en el camino "feliz" para después manejar los errores. Con esto el código se va a llenar de variables de error desparramadas por todos lados.
Justo como los try catch si tampoco sabemos manejarlos, no hay camino feliz diría yo, depende lo que se haga más cómodo para cada quien. A mi me gustaría que no se crearan diferentes scopes nada más
De eso se encargan los que desarrollan los engines, cuando se aprueba cada año las nuevas características a incluir no existe esa información porque es diferente en cada engine, aunque si debería estar incluida en algún lado
como carajo estas enterado de todo, conoces todos los detalles ni bien van saliendo y ya explicándonos , es increíble el trabajo que haces wow
Ando en el chisme de cerca 😹
Me recuerda al uso de try? await fetch() en Swift pero dado que JS no soporta opcionales con Swift, carece de sentido porque como bien comentas la firma de la función se tiene que adaptar para seguir la convención de envolver el output en un array, cuando sería más lógico añadir enums o sealed classes simuladad a lo Kotlin a la especificación de JS para implementar el patrón Result-Catch.
Tu propuesta terminó no gustandome porque después tendría que a result validar el tipado que tiene si es exitoso o no, mientras que si devuelves dos sabes que uno es la data que podría ser null y error tener algo y si error null data tiene algo, sería igual que golang, con su manejo de errores, quedaria bien al final lo de golang, pero no manches eso es solo un patrón, podrías hacer una función que retorne dos valores y allí adentro solo hacer 1 vez el try catch, ni es necesario este cambio al core de nodejs porque solo es un patron de comportamiento
Jajaja es una idea bro, y no es al core de nodejs sino a ECMAScript, son dos cosas bien diferentes, relaja la raja
@@vidamrr no lo dije en mala onda, solo es una opinión igual 😅 disculpa si sonó mal
relájate especial
Jajaja si sonó medio de reclamo pero todo bien bro 🤜🏻🤛🏻
Te sentirías mejor si te digo que me gustas? 😍 Eres lindo 😘
soy partidario del uso de la palabra "try" antes de usar ?= ya q me parece algo anti intuitivo. lo q propones tambien estaria interesante pero cae el asunto donde el parametro q recibe la funcion de error tiene q ser del estilo (xq no le se el nombre al patron) onClick={funcion} y tiene por entendido q recibira el evento onclick la funcion de error. pero tambien como manejas el tipado es engorroso ya q tienes q hacer algo de typeof y eso es un paso q se puede saltar teniendo dos variables separadas
es innecesario realmente, es obligar a malas implementaciones, no es necesario llenar de try/catch o cada nada validaciones de datos así, es bueno y siempre lo hago, es hacer un componente encargado de ejecutar y controlar las peticiones, con eso ya solo llamo en una linea corta, eso se encarga de todo y breve.
la verdad si ayuda la propuesta a simplificar las cosas, y mas con el tipdo que muchas veces se pierde al tener varios scopes, pero no me grada demaciado la sintaxis de ?=, ya tenemos suficientes operadores, la propuesta con el try expression me parece mas intuitivo.
Siento que el uso de ternarias puede complicar las cosas por que las expresiones no siempre son sencillas o cortas y tener un : flotando por ahi no ayuda con eso, ademas de que te obliga a hacer una funcion para el handler cuando no siempre es necesaria (o eso entendi de tu propuesta) y no esta claro de donde sale el error, por ultimo, terminaria retornando un typeof | undefined la expresion asi que igual el value habria que validarlo por segunda vez el 100% de las veces aunque exista un handleError ya que la ejecucion no para ahi.
el retorno de la tupla con el error primero para asegurar que manejes el error me parece mejor ya que el tipado seria un [error] | [null, typeof] que al evaluar si existe error y manejarlo te da campo libre para que por inferencia el caso contrario tengas libre usar el value, asi que aqui no el 100% de las veces habria que validar el value lo que ya es ganancia
Esta Muy interesante tu propuesta ojala te animes a publicarla, solo una duda cual es la fuente de tu editor vscode y el tema estan geniales. :´p
Eso lo tenía Swift hace años imagino se basaron de ahí
Me pregunto podría considerarse el bloque finally con esta nueva sintaxis, se ejecuaria como un apéndice en el error y result o se ignoraría
Como el error lo tienes en una variable puedes tratar el error despues de una ejecució es decir que despues de la operación try ejecutamos algo que si o si debe ejecutarse y luego tratar el error. es muy recomendable tratar el error, no por nada es un error.
Sea cual sea la decisión que tome el tc39, no va a cambiar el código actual, ya que js es retrocompatible, si se añade una sintaxis simplificada no se está obligando su adopción inmediata y los que quieran utilizarla la posible nueva sintaxis pueden usarla
y que pasa si la función handleError tiene mas de un parámetro? como sabría el interprete cual es cual? para mi no tiene mucho sentido esta propuesta, la idea de manejar los errores con try y catch es poder centrarse primero en el camino "feliz" para después manejar los errores. Con esto el código se va a llenar de variables de error desparramadas por todos lados.
Justo como los try catch si tampoco sabemos manejarlos, no hay camino feliz diría yo, depende lo que se haga más cómodo para cada quien. A mi me gustaría que no se crearan diferentes scopes nada más
puestos a proponer encuentro a faltar las estructuras centrales del ensamblador, sus registros y la pila ya que a simplificar no se va...
De eso se encargan los que desarrollan los engines, cuando se aprueba cada año las nuevas características a incluir no existe esa información porque es diferente en cada engine, aunque si debería estar incluida en algún lado
Me gusta tu propuesta
Desde mi punto de vista, sería mucho mejor copiar lo que hace Switf con su operador "try?"
Como se hace ahí? Esa no me la sé
@@vidamrr es como la propuesta de try-expresion que está en el repositorio pero ignora el error, sí falla la expresión sólo se devuelve null.
Me vale seguiré usando axios hasta la muerte xd.