[JavaScript] - Hilo oficial

Saphyel

Dado que es el lenguaje mas infame de la comunidad he decidido crear un hilo para todos los que se quieran aventurar a hacer algo de provecho en sus vidas.

Que es?

JavaScript (abreviado comúnmente JS) es un lenguaje de programación interpretado, dialecto del estándar ECMAScript. Se define como orientado a objetos,​ basado en prototipos, imperativo, débilmente tipado y dinámico.

Proyectos mas relevantes

  • VueJS
  • React
  • AngularJS
  • Yarn
  • Electron
  • D3
  • Serverless framework
  • Node.js
  • TypeScript

Ya ire editando este post cuando tenga tiempo.

4
X-Crim

Viva prototype.

1
B

Se puede hablar entonces de TS en este hilo?

Mortium

añade Angular por favor...

Leos

Por que no se iba a poder hablar de typescript?🤔🤔

1 respuesta
Ridote

Sólo de leer javascript ya se me revuelve el estómago, qué asco. @kidandcat

1
Saphyel

Se puede hablar de JS, TS, angular, etc...

kidandcat

No os quejeis, que el que se maneje bien con JS y aprenda algún framework tipo angular o react tiene trabajo seguro >20k, y eso en España ya es decir xD

Hiervan

Ahora estoy aprendiendo Angular y la verdad es que es una pasada para desarrollar páginas web. Por cierto, ¿alguien sabe de algún curso de Javascript nativo nivel intermedio en Udemy u otro sitio?

1
B

#5 bueno, no es JS puro y ha especificado AngularJS en vez de Angular a secas. Por eso la duda :D

B

.

Leos

Alguno ha hecho algo con nestJS?

Zerokkk

Una pregunta para los demás por aquí, sobre RxJs:

Llevo usándolo algún tiempo en el proyecto de la empresa y me parece cremita. No me he metido muy a fondo en la API y admito que no lo estoy aprovechando al máximo, además de estar haciendo unas prácticas que considero mejorables, pero incluso con el básico approach que estoy haciendo, me ha facilitado muchísimo la vida por ahora a nivel de frontend.

Mi pregunta es, ¿a alguien se le ocurre algún problema relativo a performance, o seguridad, del siguiente approach?:

Problema: enviar un objeto a través de un canal reactivo RxJs para poder interceptarlo y usarlo en cualquier otra parte de la app.

(demos por sentado que this.reactive es una referencia a un servicio de Angular inyectado, que recordemos que se instancia a modo de singleton, en nuestra clase)

this.reactive.channel$.subscribe( msg => {
   const parts = msg.split(":=>");
   const prefix = parts[0];
   const payload = parts[1] ? JSON.parse(parts[1]) : null;

   switch(prefix){
       // más cases...

   case "ejemplo_uso_payload":
       if(payload){
            this.hacerAlgo(payload);
       }
   }
});

// Desde otra parte del código, se enviaría tal que:

miFuncionDeEnvio(objetoAEnviar){
    this.reactive.publishMessage("ejemplo_uso_payload:=>"+ JSON.stringify(objetoAEnviar);
}

Hasta ahora me lleva funcionado de mil maravillas y es comodísimo para comunicar componentes, pero me pregunto si tendrá algún tipo de vulnerabilidad o problemática que me esté saltando.

Saludos.

2 respuestas
MisKo

#13 Lo que le veo de 'problemático' es que, tal y como lo estás indicando, tendrías un solo Observable para todos los casos y, dentro del subscribe, el switch para identificar la acción en concreto que lo ha activado.

Asi a bote pronto, lo que se me ocurre:

  • A la larga, si hay muchas condiciones, el código no será muy mantenible (sobre todo si repites cases en distintos componentes)

  • Si escuchas el mismo observable en muchos sitios/componentes ( yo que se, digamos 10 componentes ), los 10 se van a ejecutar cuando se lance next, cuando lo ideal sería que solo se activaran aquellos que le correspondan a lo que estás ejecutando.

Dentro de lo poco que he tocado de los Observables y del desconocimiento que tengo de ellos, creo que yo crearía un observable por cada case del switch (o algo así, no se q opciones puedes tener) y, cada componente solo se subscribiría a lo que les interesa.

Creo que desde esta perspectiva es algo más de trabajo en código y estructuración pero mejor a largo plazo.

De todas formas, sin conocer exactamente el uso final, cuantas veces lo usas, como lo usas, etc.. es decir, cosas que solo sabes tu, tampoco podemos sacarle muchos inconvenientes xD


## Servicio con observables

ejemploUsoPayloadObservable: Observable;
ejemploLogPayloadObservable: Observable;

## Componente 1

ejemploUsoPayloadObservable.subscribe( data => { Uso Payload; } );

## Componente 2

ejemploLogPayloadObservable.subscribe( data => { Log Payload; } );

Elitest

Yo si he entendido bien lo que hace el código directamente no usaría ni observables para ese caso. Supongo que el publishMessage será una función que hace un .next() en el servicio Reactive... Creo que es algo que podrías hacer directamente desde un servicio llamando a una función de este y pasando 2 parámetros en lugar de un string que luego tienes que cortar igualmente. Aunque igual tiene sentido lo que haces porque ni puta idea pa qué es ese código xD

1 respuesta
MisKo

#15 Como tampoco aclara y yo estoy un poco pez, he supuesto que usa RxJS.Subject para poder escuchar y emitir eventos con el mismo objeto y de ahí lo de los Observables.

De todas formas, para hacer un Next, lo haces en un Observable o en un Subject, no? xD

Repito, que no lo he tocado mucho y lo mismo digo alguna gilipoyez xDDDD

1
Elitest

Sí sí, me refería que suponía que su función llamaba al next y he supuesto algo así:

export class ReactiveService {
  private channelSubject = BehaviorSubject<string>;

  get channel$(): Observable<string> {
    return this.channelSubject.asObservable();
  }

  publishMessage(msg: string) {
    this.channelSubject.next(msg);
  }
}
export class RandomComponentOne {
  constructor(private reactive: ReactiveService) { }

  this.reactive.channel$.subscribe((msg: string) => {
     @
  });
}
export class RandomComponentTwo {
  constructor(private reactive: ReactiveService) { }

  randomFunction(entity: any) {
    this.reactive.publishMessage(...);
  }
}

Lo he puesto con Angular, pero es lo que he entendido que él hace. No sé.

Por eso tengo la sensación de que sólo se subscribe desde un sitio. :S

Haría algo así, moviendo el contenido "@" del primer código

export class PublishService {
  publishMessage(msg: string) {
    @
  }
}
export class RandomComponent {
  constructor(private publish: PublishService) { }

  randomFunction(entity: any) {
    this.publish.publishMessage(...);
  }
}

Luego me evitaría el tema de hacer un string con 2 propiedades si luego las vas a separar de nuevo, 2 propiedades a la función y fiesta.

1 respuesta
MisKo

#17 Lo de que se suscribe desde varios sitios creo que ha sido paranoia mia xD.

He interpretado de comodísimo para comunicar componentes que usaba el mismo Observable para comunicarse entre varios de ellos ( 1 observable, múltiples subscriptions ), y de ahi tambien el switch dentro del Subscribe

1
Zerokkk

A ver a ver, que os estáis liando!

Mi servicio inyectable usa un Subject al que referencio con .asObservable() para generar el objeto channel$ al que me suscribo. Ahí, en lugar de comprar el mensaje dentro, debería ejecutar .filter() sobre el mismo canal, pero es algo que no he estado haciendo (sí sé que esa es una mala práctica).

La cosa es si hay una forma realmente mejor de enviar objetos a través de RxJs. Tengo un amigo que usa un approach como el mío y por ahora sin queja, como bien decís, el problema sería para muchos números de casos o muchas suscripciones simultáneas, pero por ahora ha ido tirando bien este approach.

1 mes después
Saphyel

el 12 factor app para clis en node
https://medium.com/@jdxcode/12-factor-cli-apps-dd3c227a0e46

Saphyel

BTW tengo una oferta de react, node.js y tal de 650/dia (en londres), para mas info mp

Merkury

Aprovecho el spam de @Saphyel para decir que yo tengo oferta para Head of Frontend.

Tipicas tonterias de frontend + Vue.js
Gestion de equipos.
etc.

PM si os interesa.

Saphyel

https://slides.com/seldo/npm-future-of-javascript

Saphyel

Para los que quieran mejorar JS u otros langs https://exercism.io/tracks/javascript

17 días después
Saphyel

Un post sobre angular https://medium.com/@TobyMerk/why-angular-made-me-quit-web-dev-f63b83a157af

S

#13 Ese modo de compartir información entre componentes es horrible. Un componente debe de tener entradas y salidas de datos completamente definidas para evitar acoplamiento. Para ello los patrones mas usados son:
1 - Los decoradores input / output que ademas son la forma oficial de hacerlo, el angular way. Aparte de que evita acoplamiento ofrece una interfaz para que cualquiera entienda lo que el componente necesita y los eventos que ofrece con un simple vistazo.
2- Usando Redux. Redux se usa oficialmente en React pero también se puede usar en angular. Es un patrón diseñado para evitar cosas como la que estas haciendo.

Por otro lado es totalmente ineficiente pasar mensajes en strings cuando puedes pasar directamente objetos json sin necesitar ningún tipo de parser.

1 respuesta
Zerokkk

#26 En cierto viejo proyecto llegué a usar tanto el approach de input/output como llamadas RxJs, debido a que había requerimientos de comunicar ciertos componentes que no estaban accesibles mediante la parent view. Nunca usé Redux no obstante, y quizá debería haberlo hecho, pero tampoco fue del todo mal. Eso sí, no te confundas, claro que usaba JSON para pasar los parámetros xD.

Aunque no usase Redux, sí que tenía cierto "stateful object" que usaba para mantener los datos y cambiar cierta parametrización de los filtros y demás. Ya en los proyectos nuevos estoy prescindiendo de RxJs para dicha acción porque al final quedaban algo liosas las llamadas, aunque para determinadas cosas, en vistas con muchos componentes, no creo que sea tan mala idea. Es todo cuestión de las condiciones en las que te encuentres.

2 meses después
Saphyel

el futuro de yarn https://github.com/yarnpkg/yarn/issues/6953 parece que typescript es el futuro de js, bye flow!

8 días después
B

Tenía una web en angular, conectada a un API en node y express. Todo en un vps con servidor nginx.
Hasta ahí todo bien.

Ahora he añadido letsencrypt. Las webs bien, con https.

Pero se me ha jodido la comunicación con el API.

Me decía que un https no podía hacer peticiones http y se bloqueaba la petición.

La cosa es que no sé subsanar ahora las peticiones.

Help please.

1 respuesta
Saphyel

#29 suena a problema con el cors, que error te da ? Js no es muy con los errores pero algo es algo

1 respuesta

Usuarios habituales