#MediaComponent (A tope full de TS)
1 messages · Page 1 of 1 (latest)
Por si alguien mas quiere unirse: dejo un stackblitz base con el problema para trastear https://stackblitz.com/edit/react-starter-typescript-vogo46?file=App.tsx
:loading:
haha ha estado muy loco pero muy divertido
Xd
quiere que, teniendo un componente de React que acepta un parametro X, el resto de parametros dependan del parametro X
quiere un componente, este componente recibe un parametro "type" dependiendo del "type" debe retornar un "componente" ?
en plan:
<MediaComponent type="SVG" svgProp={'a'}/>
<MediaComponent type="Image" imageProp={'a'}/>
<MediaComponent type="Image" svgProp={'a'}/> // retorna error por que svgProp no es valido si el valor de type es Image
y ese componente sus parametros deben basarse del parametro "type"?
si, total haha
o sea, si hubiese tenido que hacerlo, pensaria bien el porque, ya que es un poco fumada
yep
pienso que si sabes el tipo... por que no utilizas el componente de SvgComponent directamente?
si sabes el tipo, sabes que componente debes utilizar
yep
muy raro
lo que quiere hacer
okay
basandome en lo que dijo
type ComponentTypes = 'lottie' | 'image' | 'svg'
type ComponentType<T extends ComponentTypes> =
T extends 'lottie' ? { id: string } :
T extends 'image' ? { src: string } :
T extends 'svg' ? { source: string } :
never
const component: {
[key in ComponentTypes]: (params: ComponentType<key>) => ComponentType<key>
} = {
'lottie': (props: ComponentType<'lottie'>) => {
return { id: props.id }
},
'image': (props: ComponentType<'image'>) => {
return { src: props.src }
},
'svg': (props: ComponentType<'svg'>) => {
return { source: props.source }
},
}
function Component<T extends ComponentTypes>(
type: T, params: ComponentType<T>
): ComponentType<T> {
if (type in component) {
return component[type](params)
}
// Never
return {} as ComponentType<T>
}
eso cumple en teoria con lo que quiere
asi que
nomás que el lo adapte a (j|t)sx y sus necesidades referiendome a las props de los componentes
y si eres alguien que le gusta la palabra clave
"new"
puedes hacer algo como
function _Component<T extends ComponentTypes>(
type: T, params: ComponentType<T>
): ComponentType<T> {
if (type in component) {
return component[type](params)
}
// Never
return {} as ComponentType<T>
}
const Component = _Component as unknown as {
new (type: ComponentTypes, params: ComponentType<typeof type>): ComponentType<typeof type>
}
aunque
lo que es return
debes cambiarlo por
this = ...
y tendras que hacer algunos cambios
porque
typescript se confunde
xd
entonces solo usa este mejor
lmao
Yo lo que entiendo es que lo que quiere es algo por este estilo
enum Mapper{
SVG,
IMAGE,
}
interface svgProps extends componentProps{
svgProp1: number,
}
interface imageProps extends componentProps{
imageProp1: number,
width: number,
height: number,
}
interface componentProps{
source: string,
}
function SvgComponent(props){
return `<div>${props}</div>`
}
function ImageComponent(props){
return `<div>${props}</div>`
}
function ComponentFactor<C extends componentProps>(typ: Mapper, props: C){
switch (typ) {
case Mapper.SVG:
return `<SvgComponent ...props>`;
case Mapper.IMAGE:
return `<ImageComponent ...props> `;
}
}
// Valid SVG
ComponentFactor(Mapper.SVG, {source: "SomeValidLink", svgProp1: 1})
// Valid SVG but ignore invalid props in rest destructuring
ComponentFactor(Mapper.SVG, {source: "SomeValidLink", svgProp1: 1, imageProp1: 10})
// Valid Img
ComponentFactor(Mapper.IMAGE, {source: "SomeValidLink", imageProp1: 1, width: 600, height: 800})
// Valid Img but ignore invalid props in rest destructuring
ComponentFactor(Mapper.IMAGE, {source: "SomeValidLink", svgProp1: 1, imageProp1: 2, width: 600, height: 800})
El problema radica en el rest, porque por mas de que el linter te avise que prop.x no pertenece a Mapper.Type, hay 2 soluciones:
1: Strict mode para que no transpile esos errores
2: Generar Mapper.Type props a partir de las keys de las interfaces (El cual con Object.fromEntries e ir iterando sobre el keyof Mapper.Type interface y en la iteracion hacer un { [iterKey] : propsComponentFactor[iterkey]}
:loading:
explica
porfavor
Los components los puse en `` porque uso el sandbox de typescript xd La verdad dudo en usarlo por ahora y el Arch lo instale hace poco
Yes
En typescript es muy xd generar algo tan dinamico
De ser nada mas que Typescript le rechace la prop invalida entonces sus soluciones esta okey
: {
// Le decimos que hay propiedades que pueden ser desconocidas
[key: string]: any,
// Aca definimos las conocidas
}```
Claro ahi compones las key validas del componente
Its Okey
Como te digo, TS es en tipado muy por encima xd Y depende de la config del transpilador el si te pasa un error o no xD
Xd
ostras Flames, me flipa esta solución. Me gusto mucho el uso de conditional types, y desconocia que se podia hacer el [key in ComponentTypes], para utilizarlo luego en el Generic
xd
Esta bastante clean
Queda extenso si el componente usa muchas keys pero bueno xd Ya creo que es mucho la solucion
o sea, has visto el mio ???? esta recontra complicado haha
xD El tuyo es muy verbose, ese es el problema
si añades algo en el enum Mapper, se te queja en otras partes de que no esta implementado?
no habia pensando sobre los enumeradores
pero creo que prefiero pasarle un string directamente que
MyEnum.<Num>
Y el enum es lo unico que pasa de TS a JS, asi que supongo que si, el tema es que usando un enum estas forzando a implementar las props del componente y no dejas un caso sin handlear
pues
me referia aquí
Enums permite pasarlo a Strings, estilo
enum Mapper{
SVG = "SVG"
}
TS te da una "defensa" "superficial"
ya pero lo vuelve un objeto
xd
less code
o sea, si no haces nada raro con Typescript, te blinda bastante bien los tipos
No, lo vuelve una funcion o en algunos casos el value, depende del transpilador
yep
aun asi
una vez estando JS
le puedes meter cualquier cosa
typescript deberia transpilar el tipado
Esto es raro xD
no hay tipos de nada
ejemplo:
Por eso se hizo el hilo
bueno, me parece avanzado, mas que raro
Pero creo que ya se llego a la solucion con lo que puso Flames
siii
function (a) {
if (typeof a !== 'string')
throw new Error('Expected string')
}```
deberia eso hacer typescript
a la hora de transpilar
pero no lo hace entonces xd
ah, ya. yo si quiero hacer algo que viene de la api de un tipo, creo una funcion especifica
Mmmm no se si avanzado, en si es un Factory Pattern pero con Typescript dinamico xD
un lugar de hacer as Person por ejemplo
tal vez
hago un metodo, llamado `aPerson = (x: any): Person => { // hago todas las comprobaciones para saber si es person o no}
he usado bastante TS con tipados "dinamicos"
entonces
me resulto relativamente sencillo encontrar al solución xd
Si entiendo la funcion de Typescript, el tema es que hay cosas que me parecen raras, igual creo que con un mes leyendo la doc ya las voy a ir dominando 
yep
aunque no vendria mal que typescript lo transpile directamente el tipo
te ahorras eso
pero bue
es lo que hay
bueno cracks, me encantó compartir nuestras soluciones. He aprendido mucho!
Si es en OOP no es tipado dinamico si no mas bien dynamic Dispatch, tienen sus diff y eso es lo que me sorprendio de TS
Same
ya ves
no suelo tocar mucho la oop
lo funcional
es relativamente mejor
los programadores en oop suelen hacer mucha cosa rara
e innecesaria
Tu me avisas y arreglamos en VC para charlar, que necesito entender unas cosas de TS y sus implementaciones de extends, implements y distintas keywords xD
toco mas eso
incluso cuando hice un juego para mi mismo
lo hice funcional
Xd
yo recién me estoy introduciendo
No hay paradigmas mejores o peores, hay paradigmas que para x situacion sirven mas que otros
potencialmente si
todo el tema de currying, partial application, function composition, etc
la poo tiene sus ventajas
pero
a veces no son necesarias
y hacen cosas innecesarias
minecraft moment
pero bueno
no estoy en contra del a poo
si saben usarla correctamente
esta bien
pero prefiero usar estructurado o funcional
el rollito de la inmutabilidad da bastante calma mental
El problema del OOP no es el paradigma en si, es el programador, yo te voy a hablar de Rust que es donde mas conocimiento tengo, puedo implementar la misma solucion a varios problemas tanto funcional como OOP based, funcional en muchos casos es mas problematica que el OOP y viceversa
es a lo que queria llegar
la oop no es mala
pero no saben usarla
Claro ese es el problema el OOP, y de que muchos programadores que optan por usarlo pero mal, no entienden los principios basicos ni saben componer dichos Objetos
yep
Exacto, en eso estamos de acuerdo
Bueno, quedo lindo el hilo n.n Nos estamos viendo por alguno de los channels
por cierto @north current , intente usar el conditional typing, pero sin el [key in ComponentTypes] , que desconocia, no sabia que fallaba haha
nos vemos!!
Xd
@jagged yoke desde aca puedes empezar revisar el contenido que se mando
Buenas Chicos como estan, les agradezco banda todo lo que hicieron ,entiendo que esto es super raro, pero me puse en modo terco y queria hacerlo y aprender el porque no se podia.
Esto sirve mas que nada para tener un componente super dinamico.
Estuve tratando de hacerlo pero tenia el problema al pasarle las props a cada componente ya que ts no sabia que props enviarle a cada componente
Genial igualemnte voy a revisar todos los mensajes para no perderme ninguna conclusion gracias 🙏 🙏 🙏
espero que hayamos podido solucionar tu problema
Muchas gracias seguramente ahora estoy leyendo todo cualquier cosa les aviso