#238 el spread es shallow
#238 el tema es tipos primitivos vs referencias.
const a = 9
let b = a // se crea b en el stack con valor 9
b = 5
// a === 9, b === 5, b !== a
Pero con referencias
const a = { value: 1 }
const b = a // se crea b en el stack como un puntero a la misma dirección en memoria a la que apunta a
b.value = 2
// a.value === 2, b.value === 2, a === b
Cuando haces un spread del array a, que tiene referencias, y lo asignas a b: a y b son arrays distintos, que apuntan a distintas direcciones de memoria. Pero como los elementos en a no son tipos primitivos, no se han copiado sus valores. Los elementos de ambos arrays son punteros distintos, pero apuntan a la misma dirección (a[0] y b[0], por ejemplo, apuntan al mismo objeto, por lo que a !== b pero a[0] === b[0])
PD: lo mismo pasa con el spread en objetos:
const a = {
numero: 23,
obj: { numero: 25 }
}
const b = { ... a }
b.numero = 99
b.obj.numero = 99
// a: {"numero":23,"obj":{"numero":99}}
// b: {"numero":99,"obj":{"numero":99}}'
10 días después
Me gustaría empezar a aprender Javascript.
No se muy bien a donde acudir. Tiro de YouTube?? Udemy? Me recomendáis algún curso en concreto??
Empezaría de 0. Nunca he programado en ningún lenguaje. Hace años toque HTML y CSS pero fue poquísimo y hace tanto que ni me acuerdo.
Gracias 
#245 Si no tienes problemas de inglés, este me parece muy bueno.
https://www.udemy.com/course/the-complete-javascript-course/
#246 en español hay algún curso rechulon?? 
Cómo recomendáis empezar?? Ese curso o por ejemplo ir a Youtube directamente
Gracias!!
#247 Si no te importa pagar 10 euricos, Fernando Herrera tiene cursos muy buenos, entre ellos este:
Cabe decir que este en concreto no lo he hecho, pero tengo suyos dos de angular y uno de ES6 y tiene mis dieces.
Por experiencia personal, Fernando Herrera me gusta como imparte, aunque sus cursos se podrían reducir bastantes horas.
Eso sí, hace mucho hincapié en las cosas y te enteras de todo.
Estaba viendo un video sobre Remix de un tio que tiene bastantes seguidores y he visto algo en su código que he estado viendo ultimamente en las pruebas técnicas que ando corrigiendo en mi empresa.
Hablo de usar let para absolutamente todas las variables, sin hacer distinción con const, a pesar de que no estás reasignando esas variables.
Alguien sabe si esto es una nueva "moda"? O si resulta que hay algo que me estoy perdiendo? Tengo bastante curiosidad.
He visto esto: https://jamie.build/const , pero sinceramente el tono me parece un poco tonto y me parece que fuerza mucho el decir que usar const no tiene sentido mas que para una cosa y preferiría oir otras opiniones.
const FOO = { prop: true };
FOO.prop = false; // LINT ERR >XD
¿Lint Error de que? Que no tenga actualizado o bien configurado su linter no quiere decir que eso no sea correcto. Cuando dices que es constante dices que es constante la referencia... si la referencia es un objeto mutable este objeto debería o bien hacer lo propio con el atributo dado o "congelar" el objeto.
Also, V8 and friends have been doing these optimizations without const for a really long time. Benedikt or Franziska or whoever can correct me if I'm wrong, but Babel definitely can already do this shit.
¿Babel? ¿que pinta un transpilador en optimización a ese nivel? ¿No se quiere referir igual a turbofan?
Guíate como está escrita la documentación... por ejemplo en: https://developer.mozilla.org/
Los que usáis express cómo resolvéis la consistencia de la api? Lo que quiero es que lo que está al nivel de controller no tenga que decidir cómo se resuelve el resultado de los servicios de dominio o las capas que tenga por debajo, si no que se resuelva por encima, como si fuera un middleware más o menos.
Lo que he hecho ahora es tener una higher order function que devuelve el callback que envolvería el resultado de la lógica del controller, pero se me hace algo raro y no sé si es porque no controlo de javascript o porque es raro a secas.
Pongo el código de ejemplo
Cómo se forma el router:
router
.route("/")
.get(wrap(getHello))
;El wrap con la lógica para gestionar los errores (el result es un tipo que tengo por ahí para envolver un valor):
type controller = (req: Request, resp: Response) => Promise<Result<any>>;
export const wrap = (fun: controller) => {
return async function(req: Request, res: Response){
try {
const result = await fun(req, res);
if (result.isSuccess()) {
res.status(200).json(result.Value);
} else {
res.status(500);
}
} catch(err) { res.status(500); }
};
}Y esto ya sería lo que tiene la lógica a nivel de controller:
type Greeting = { greeting: string; }
export async function getHello(req: Request, res: Response)
: Promise<Result<Greeting>> {
return Result.ok<Greeting>({greeting: "Hello world!!"});
}Si se ve algo descuadrado/que falta es porque he limpiado un poco el código al ponerlo aquí.
#234LzO:El de Jonas está gratis a través de hidevs.net y lo estaba haciendo y Frontend Masters lo conocí hace 2 semanas y tiene una pinta increíble también.
Acabo de ver esto de Hidevs y los cursos gratis de udemy ahí.. ¿Eso es legal? ¿Es gratis por los autores o subido destrangis? Muy interesante.
15 días después
Dejo una pequeño mindfuck de Typescript a ver si alguien tiene la respuesta.
const enum Fruits {
Apple,
Orange,
Kiwi,
}
function getTest1() {
return Fruits.Apple;
}
function getTest2(foo: boolean) {
if (foo) {
return Fruits.Orange;
}
return Fruits.Kiwi;
}
const test1 = getTest1();
const test2 = getTest2(true);
If you check the type of test1 you will get Fruits.
If you check the type of test2 you will get Fruits.Orange | Fruits.Kiwi.
I would expect that it would be easier for TS to actually know that getTest1() can only return Fruits.Apple , but instead it thinks that it is Fruits.
I could fix it by switching the content of the function to: return Fruits.Apple as const; but it definitely doesn't feel like it's the way to go.
Alguien sabe explicar por que y como lo solucionaría?
Esa es una opción desde luego, pero en este caso quiero evitarla ya que TS ha mejorado mucho con los años y no hace falta ser explicito a la hora de declarar lo que devuelve una función.
En este caso getTest1 puede cambiar lo que devuelve y no quiero estar especificando manualmente en la definición de la función los posibles tipos ya que ya lo hago en el código.
Me cuesta mucho resignarme y aceptar esto sin entender por qué no está funcionando como debe en el caso más sencillo.
#258 Yo diría que como en 'getTest1' ya tiene la respuesta directa... te dice que es Fruits... pero con 'getTest2' no tiene la respuesta directa y lo saca por inferencia 'Fruits.BLABLA | Fruits.BLELBE' ... parece que si todos los posibles valores coinciden con un enum (en su totalidad de posibles valores)... se da como resultado ese Enum... si no, despliega cada una de los diferentes resultados.
P.D: No he picado directamente TS en mi vida hulio... no me hagas mucho caso.
13 días después
Buenas, tengo la necesidad de tirar de cookies para la implementación de un carrito de la compra, por lo que, aprovechando esto he pensado en re-utilizar esta cookie para hacer unas recomendaciones en base a los artículos que este usuario tenga en su carrito.
Ahora bien, no sé si tirar de la misma táctica podría funcionar ni tampoco si es la opción más recomendable.
Mi app también tiene BD pero supongo que tirar de cookies es más liviano y eficaz.
#260 Las cookies tienen límite de tamaño y, además, vas a estar "grapando" toda esa información a cada petición que le hagas al servidor (aunque estés pidiendo una imagen)
Puedes usar cookies para asignarle a ese navegador una sesión, que controles desde el backend (busca "cookie de sesión"). En vez de usar cookies para guardar cada artículo, también puedes tirar de almacenamiento local, con IndexedDB.
Una web "famosa" que tira de cookies para todo es la de El Corte Inglés. Si navegas lo suficiente y haces varios pedidos online, te vas a encontrar con cookies corruptas, fijo que por el tamaño. Las imágenes dejan de cargar, etc, hasta que limpias las cookies.
Interesante imagen que he visto por Twitter, que pensáis?
Yo tengo un sesgo tremendo ya que trabajo con React pero una cosa que me gusta es que es facil distinguir entre JS y HTML gracias a JSX, la capa es bastante fina comparado con los otros dos frameworks.
#262
QWeb...
<ul>
<li t-foreach="items" t-as="item" t-esc="item.name" />
</ul>
o...
<ul>
<li t-foreach="items" t-as="item">
<t t-esc="item_index"/>. <t t-esc="item.name">
</li>
</ul>
o...
<ul>
<t t-foreach="items" t-as="item">
<li>
<t t-esc="item_index"/>. <t t-esc="item.name">
</li>
</t>
</ul>
#264 A mi me parece lo contrario por temas de que Vue entra inline, react te fuerza a utilizar JS nativo junto a JSX, pero los otros intentan...como crear su propia sintaxis because potato
#265 en lo sencillo, ordenado, estético y funcional que queda. Y mira que yo no toco Vue, pero me gusta más ese rollo que meter prácticamente un script entero de js para crear componentes.
yo prefiero usar js antes que ponerme a revisar si lo que leo es "html nativo" o tiene lógica del template engine
Buenas noches. A ver si me podeis explicar esto porque no lo entiendo. Por más que lo leo no lo entiendo y aunque me da cosa preguntar esto porque sera una obviedad, prefiero que alguien me llame retrasado y me lo explique a pasar a la siguiente leccion y no saber por que.
Estoy haciendo el freecodecamp y el enunciado dice: (lo meto en spoiler todo para no ocupar quince paginas)
Y el codigo que dan es este:
la respuesta es meter esto donde toca:
arr.push(item);
return arr.shift();
Y no entiendo por qué. El push y el shift lo habia puesto pero poniendo testArr.push() y tambien con el shift y me daba ok las 2 primeras partes, pero el resto no.
Lo que no entiendo es por que pushea el arr con el item en parentesis y luego el shift. Bueno, no entiendo por que funciona asi. Se que el push le mete un numero mas al testArr? y con el shift le quitas el primero, pero no me aclaro nada de nada como funciona.
Pediros disculpas si es una puta mierda de pregunta, pero es que no voy a dormir tranquilo sin entenderlo xD
