🛑 4 cosas a EVITAR en TypeScript + 1 en JavaScript (¡Pero no estoy de acuerdo en todas! 😱)
ฝัง
- เผยแพร่เมื่อ 9 ธ.ค. 2024
- Te explico 4 características que un artículo dice que deberíamos evitar en TypeScript y también por qué creo que no deberías usar getters y setters en JavaScript (pero sí en TypeScript).
Aunque la información del artículo es interesante, no estoy de acuerdo con todo y te expongo los motivos. Al final, tú decides. :)
Desde que aprendi typescript y nunca mas volvi a codear en js. Las empresas lo piden y suma bastante saber typescript
Hay un caso de uso concreto donde los namespaces son una bendición.
En NGXS a la hora de crear las acciones, que son clases y que tienen todo el sentido tener todos en un único archivo, el namespace ayuda a poder encapsular todas estas clases en un único namespace que funciona como una especie de clase padre estática donde residen todas las clases de cada una de las acciones y no tener que importarlas una a una, sino con importar todo el namespace ya tienes acceso a todas las acciones
yo creo que cuando el proyecto es muy gigante. es recomendado usar namespace. pero si es un proyecto mediano o pequeño. es mejor hacer los import| export.
Yo despues de ver 5 segundos de video: Muy buen video, sigue asi
El enum tiene un downside no mencionado, y es que si lo defines sin usar const, se transpila en un objeto con todos los key: values, pero si lo defines con const, solo se compilan los usos del mismo. Interesante, no te parece?
Estoy de acuerdo con todo lo que se expone aquí, aunque podría opinar acerca de los namespaces si se me permite.
Estos son más una forma de organizar proyectos en los que existe una gran cantidad de clases que muchas veces no se sabe de donde vienen, si son nuestras o de librerías third party.
No es común en Javascript/Typescript pero es una práctica que se lleva a cabo de antaño un lenguajes como C# y Java (los padres de Typescript). Aunque entiendo que Javascript ya contaba con módulos que hacían algo muy similar.
Es un error pensar que un namespace solo puede vivir en un archivo. Y La verdad sería mala práctica tener todas las clases/métods de un namespace en un mismo archivo. Mis condolencias al que tenga que mantener eso.
Un ejemplo útil podría ser que si escribo una librería de conversión de archivos multimedia, podría tener los siguientes archivos.
- namespace Converter.Audio:
- - MP3Converter.ts : namespace Converter.Audio { export class MP3Converter { ... } }
- - OGGConverter.ts : namespace Converter.Audio { export class OGGConverter { ... } }
- namespace Converter.Video:
- - MP4Converter.ts : namespace Converter.Video { export class MP4Converter { ... } }
- - MOVConverter.ts : namespace Converter.Video { export class MOVConverter{ ... } }
Y para usarlo en mi "codigo cliente" sería:
import Audio = Converter.Audio; // imports
import Video = Converter.Video; // imports
... { code here } ...
new Audio.MP3Converter();
new Audio.OGGConverter();
y...
new Video.MP4Converter();
new Video.MOVConverter();
... { code here } ...
Sinceramente lo único que no me gusta de esto, es tener que llamar al namespace antes de llamar a la clase, pero tiene sentido para evitar que dos clases con el mismo nombre en diferentes "paquetes" entren en conflicto.
Soy fan de tus videos... Después de escuchar el video me he quedado con la mosca sobre los decoradores. Estaría genial que hicieras un video explicativo porque es algo interesante. ¡Gracias! Y enhorabuena por el canal!! Happy coding!
Es que no entiendo porque mezclar los usos. Una cosa es que un framework te de decoradores para extender clases propiedades etc para poder hacer cosas en automático (definidas por el framework) y otra es que uno de ponga constante a programar todo con decoradores.
Utilizar namespaces puede ser una muy buena práctica para definir tipos
Yo cuando aprendi Unity con C# y vi los namespace tenia miedo. Hasta el dia de hoy sigo sin entender para que sirven pero mejor los tengo ahi sin tocar nada
Decorator es un patrón de diseño que permite agregar responsabilidades de manera dinamica
Aquí en México cuando uno dice "Si no les gusta, pues nada" es "Si no les gusta, pues a chingar a m4dre", cuando lo dices pienso que dirás eso jajajajajaja excelente video
Muy buen video! Concuerdo en que todas las razones para no usar Typescript no tienen sentido.
Entiendo que este video tiene bastante tiempo pero realmente no estoy para nada de acuerdo respecto a las properties.
Es importante entender desde mi punto de vista que aclaraste respecto a JS pero por otro lado es importante entender para que sirven, el rol de las properties es para poder generar abstracciones en donde su especificacion este 100% separada de su implementacion. Claramente este concepto en JS no tiene mucho sentido pero en Typescript cobra una fuerza muy grande ya que podes tener diferentes implementaciones que respeten una misma interfaz en donde su estado puede ser diferente.
Esbuild es una gran herramienta para transpilar typescript super rápido, pero no soporta algunas cosas de typescript como los decoradores.
Un namespace no solo es usado para encapsular funcionalidades, de hecho esa cualidad es secundaria. El objetivo real de un namespace es poder definir una función con el mismo nombre y parámetros pero con diferente implementación en 2 o más módulos. Claro que está opción es aplicable cuando el polimorfismo no puede ser usado.
Un buen ejemplo de uso de namespace es cuando se necesita enviar información por medio de diferentes canales de comunicación, los cuales siempre tienen las mismas funcionalidades, get, post, send, receive etc, pero con la diferencia de que la implementacion para cada canal es totalmente diferente y usan diferentes APIs. en ese caso el polimorfismo no es aplicable solamente se puede resolver con namespaces, claro, si es que no se quiere tener un nombre de función diferente para cada canal de comunicación.
namespace Serial
{
export function receive(s: string){
//implementación para recibir data por puerto serial
}
}
namespace Socket
{
export function receive(s: string){
//implementación para recibir data por socket
}
}
Esto viene de C++, verdad? o recuerdo mal.
solo se eliminaria si es un 'const enum', de otra forma usa un diccionario
Cual es el nombre del tema para visual code que usas amigo ?
confirmo el ejercicio de la prueba tecnica 22:03
@midulive midu, tengo entendido que los emuns de typescript se compilan a JS, en forma de funcion. me parece haberlo visto de hecho en playground oficial, asi que no tiene costo 0. saludos!
Interesante, en tu opinión es buena o mala práctica?, donde usaste el playground?
Buenas, has visto los modulos federados, vas a sacar video de ellos?
private verboso? El private es unaa sintaxis común de los lenguajes de programación orientados a objetos, y los lenguajes de programación orientados a objetos de por si son verbosos .Luego vamos a tener tipos de datos de javascript como: i, f, d, s, da, b, y c, para que no sean tan verbosos porque int, float, double, string, date, boolean y char son verbosos.
Tú lo dijiste, para esos lenguajes, JavaScript no es un lenguaje orientado a objetos, sino a prototipos. Me encanta C#, pero son diferentes; también, el # permite identificar visualmente una propiedad privada al usarse y no solo al declararse, útil en un lenguaje dinámico como JS.
Lo típico, si quieres algo similar a enums usar propiedades estáticas
yo tengo un problema con el linter y los enums... siempre me dicen que el valor no se está usando... cual seria el problema?
:thinking
Js deberia ser ts nativo sin transpilador, y al menos dejar las malas prácticas en js he encontrado code que madre mia calladito me quede para no discutir o caer mal a los otro programadores al final node debería permitir de forma nativa y el tipado debe estar en tiempo de ejcucion y la llamada de error por que muchas veces no coincide la linea de error del codigo con el transpilado
yo uso enum pero acabo de encontrarme con un problema serio y que me veo obligado a "bajar mi consumo de enums"
Ejemplo:
enum EAnimal = {
GATO = "gato",
PERRO = "perro",
TIGRE = "tigre"
}
//quiero definir una variable que SOLO acepte un animal domestico
let domestico :EAnimal = EAnimal .TIGRE; // ⚠NO quiero que me sugiera tigre, es peligroso.
//Usando tipos:
type TAnimal = "GATO" | "PERRO" | "TIGRE";
type TAnimalDomestico = Exclude; //solo domésticos
let domestico :TAnimalDomestico = "TIGRE" //🚫 Error, Tigre NO es domestico;
Enum es rígido, tipo es flexible y adaptable
Minudev , excelente aporte y video!!, no me digas que te pasaste ya a typescript o le estas hechando ojitos para usarlo pronto en tu dia a dia?? 🤣🤣
Los namespaces podrías usaarlos como en c#
Los decoradores muchas veces rompen SOLID porque hacen magias que dotan de segundas finalidades a una clase, un repositorio es un repositorio no es un repositorio que a su vez publica mensajes en rabbit y que a su vez manda un mail
Las cosas tienen su razón de ser y su sitio donde ir, no confundamos resolutividad con chapuceria
En cuanto a lo de private estoy en desacuerdo porque mejor un codigo que se explica solo que un código que hay que adivinar, hay que programar también pensando en los demás y si viene un junior al equipo mejor que de primeras sepa que es privado porque lo pone y luego que aprenda con el hash si quiere pero que sepa el trasfondo del asunto
No es necesario aplicar Solid a todo. Aparte la funcionalidad de un decorador de puede disfrutar a nivel framework. No es tan del programar un decorador todos los días sino usarlo de seguido.
A mi no me gustan los enums porque tenes que exportarlos por toda la aplicación. Prefiero declarar un type con ORs de las cadenas válidas
Yo pienso parecido. No me funciona igual que otro lenguaje. Y aparte dónde lo necesite me sirvió mucho usar keyoff en vez de un enum.
buen video🎉
Eres un duro!
lo de los enums creo ya lo solucionaron, ahora ya estan fuertemente tipados
Desconocía que el # se puede utilizar como modificador acceso de forma nativa en JS y también los problemas de utilizar las expresiones set y get tus videos se me han hecho interesantes, un saludo amigo
en lo personal, la sintaxis debería estar hecha para humanos, no para máquinas… el uso de # como privado en JS, no es descriptivo, a menos que sepas la especificación de JS. Es decir, el código debería ser fácil de comprender. Todo parte de una filosofía, y necesidades de integración técnica, entre otros…
Coincido, me parece mucho más descriptivo el uso de private
public static void main(String[] args) enjoyers be like..
-1 al argumento sobre los enums, para mí son la vida 😂
Pienso igual!
simplemente javascript es sorprendente, siempre en evolucion en su eterna busqueda de ser un lenguaje decente xD...
y typescript que ya es algo decente, pero innova para ser cada vez innecesariamente mas "complejo"....
Totalmente de acuerdo que estupide de razón para np usar enum.... no usemos ts y listo claro
Team underscore -> __atributo sin dudas
el # es muy feo pobrecito, me recuerda un poco al id en css, creo que podrian implementar algo como C++
donde pones private: y todo el codigo que quieras debajo de eso será privado, igualmente typescript a muerte👻
typescript es tu 9/10 solucion >o< pa esas mierdas
Hola si tengo definido un type, cómo puedo clonar esa estructura hacia una clase? por ejemplo:
type persona = {
nombre: string
edad: number
}
y lo que deseo obtener es:
class persona {
nombre: string
edad: number
}
El # para los private es un "Anti-Pattern" 😂 bromeando.
Namespace es util cuando se trabaja en equipo y luego hay que unir los módulos
¿Por qué mierdas estandarizaron JavaScript con tantas porquerías?
Eso no es JavaScript. Es TypeScript.
@@midulive TypeScript es lo que debió ser JavaScript desde un principio de los tiempos, pero que por razones egoistas no se dió.
JavaScript, con su mentira de la flexibilidad, inventó una cantidad de malas prácticas que nisiquiera se pueden abarcar en un curso dedicado a ello.
Muchísimas cosas se pudieron hacer y evitar, grandísimas cantidades de dinero se pudieron haber ahorrado y se pudo ahorrar el desarrollo de tantas tecnologías que hoy se venden como novedosas, cual lo último en iphone de la semana, y que hacen que millones de personas gasten en cursos y tutoriales billones de dólares y demás dinero en todas las denominaciones del mundo, tiempo y esfuerzo absurdamente desperdiciado, para que al final se aprendan tecnologías sobre del sobre lenguaje que evidentemente son un montón de tapahuecos y parches sobre las embarradas que JavaScript fomenta.
@@midulive El tipado fuerte pudo ser considerado como una manera de establecer seguridad y control, para el uso de variables, objetos y funciones, pero debido a que jamás se dedicó esfuerzo en ello, se han fomentado las malas prácticas de la programación con un lavado de cerebro brutal, ahora simplemente se consideran como herramientas para ayudar al programador a escribir su código.
Incluso se podría establecer mejores funciones y métodos del lado del Kernel para optimizar el rendimiento del código, e incluso, existen tésis que tratan sobre protocolos de comunicación más ágiles que se pueden implementar cuando el código fuente posee buenas prácticas de programación en su fondo.
Los militares siempre se llevan las mejores tecnologías. 😒