Tutorial Javascript | Evita usar If - Else o Switch, usa esto!

En este video hablamos de cómo podemos mejorar nuestro código para dejar de usar tanto los If - Else o Switch con el objetivo de tener un código mas legible y fácil de entender.

🔔 No te olvides de suscribirte y activar la campanita

—

Mi setup:

Ordenador: iMac 5K 27'' 2017
Cámara: Logitech Brio 4k
Ratón: Logitech MX Master 3
Teclado: Apple Magic Keyboard US Layout
Micrófono: Shure SM7B
Brazo de micrófono: Rode PSA1

[diegowagner]

No se si confiar en alguien con un IDE blanco jajaja

[dbatista]

En mi equipo usamos esta estructura, pero no es para todos los casos. Muchas veces hacer esto hace mas complejo leer código, mucho más para la gente nueva que entra el equipo, sin embargo, se ve elegante y se puede extender mas facil la funcionalidad. No lo llamaría "Evita usar If/Else" al video, o quizas para click bait si sirva en youtube jeje

[abelpadilla]

Muy buena idea, lo he utilizado.
El tema es cuando tienes comparaciones más complejas, con .includes() por ejemplo

[nayarithjimenez]

Que genio!! me acaba de solucionar un complejo que tenía por no querer utilizar switch ya que se ve feo, así como lo muestra y en el caso que estoy manejando se ve bellísimo, me encantó.

[Jel.Awesh.M]

Buenísimo, muy buena idea...veré si puedo trasladarla C# que es donde suelo desarrollar...

[cesaraugustotapia]

Ese metodo se puede utilizar en cualquier lenguaje de programación.

[hannsmp]

muy interesante el uso del objeto y sus propiedades, yo lo uso en como operadores, un objeto con propiedades con el nombre de un operador y devuelve una función donde entran los valores a operar

es muy legible y rápida

[armandoWebDev]

Al handler se podria asignar con una función en vez de leer el objeto directamente y en dicha funcion colocar un guard statement en caso de que el user.notificationType recibido no sea valido o no esté presente en nuestro objeto que encapsula las funciones.

[elieje]

Me encanto, Rápido y Claro.. Gracias Albert men... Que este Bien.

[kmiiloberrio-dev]

Muy buena forma, aunque para que se vuelva un poco mas mantenible, seria aplicar OpenClose a esta función que ejecuta el handler, ya que si hay nuevas formas de ejecutar notificaciones tendremos la necesidad de modificar esta función, aprovechando un poco de Polimorfismo podríamos lograr algo mas mantenible.

[daniel-gra]

Me parecio excelente y explicas super bien man, es bello ver ese codigo simplificado, mas legible y mantenible

[valerianavarro]

muy útil para cuando tenemos varios if anidados

[rafaelmendez]

no dejo de aplicar esta forma, es muy escalable y si lo combinas con expresiones regulares y spread operator se vuelve super útil para formularios y con mucho menos lineas de código aunque con la desventaja de que es un poco dificil de entender para un novato

[aldoprogramming]

Siempre me pregunte en como dejar de usar if o switch, Gracias querido!

[joaquinlabrador]

Muy buen contenido y yo todo viciado al if, else if etc... hora de cambiar de formas!

[IdequelBernabel]

YT me recomendó una joya! Suscribed!
Excelente video!

[lopuma]

Hola, que extensión unas para el ===, => para que te lo muestre como lo tienes??

Me podrías decir por favor

[escudodeplata]

Lo cierto es que parece ser muy útil, para operaciones sencillas y quizás algunas intermedias. Pero para algunas más complejas, creo que seria mejor usar los if y switch. Al menos esa es mi opinión, la verdad no estoy seguro, acabo de ver el video, y no lo he probado todavía.
Pero esta muy bueno. Gracias por el dato.

[juanpablomezagazabon]

Tengo el siguiente caso, imagina que quieres refactoizar la estructuras de condicionales que tienes en tu código. Pero tienes el siguiente escenario: Hay updateBuilder automático, que dado el caso de un producto x, se deba agrergar al builder... por ejemplo: necesitas hacer una normalización del producto y los métodos del updateBuilder son: setQuantity, setDescription, setPrice, setName, etc

Si sólo necesitas actualizar el precio para un producto en particular, el refactor que planteas funciona....
Pero si necesitas actualizar varios campos para un producto en particular, no se podría implementar dicho refactor, porque sólo está contemplado para que trabaje con una sola condición. (También es muy costoso mapear las reglas de actualización de campos para productos particulares, porque son muchos y muy variables)... la idea es que sea lo más dinámico posible.

el código que planteo sería el siguiente:

swtich (producId) {
case 0001:
updateBuilder.setName(name)
break;
case 0002:

break;
case 0003:
updateBuilder.setPrice(price)
break;
default:
// alguna excepción de código inválido
}

Cómo se podría refactorizar el código teniendo en cuenta esa lógica de negocio?

[rick_from_yr]

Me gustó, y lo usaré para esos switch que tengan más de 5 o 7 cases, para menos creo que es más legible el switch