#208 En mi opinión el refactor no sería enfocado a React como tal. Te dejo aquí mi sugerencia sin entrar a modificar tu método randomSymbol
#211 Estamos en modo leetcode?
Te lo subo a:
const getRandomSequence = (array, n = 1) => [...Array(n).keys()].map( (e,i) => randomSymbol(array) );
#211 Uff gracias, veo que estoy bastante verde. Creo que lo entiendo excepto el argumento "n = 1". Le pasas el número 1 al definirlo para decir que es un número? Por qué no pones "n" a secas y después le asignas el número 3 como haces en sequence?
Me queda claro que en el State, cuanto menos haya mejor.
#212 Me quedo to'loco
#215 Haces una arrow function que acepte dos argumentos, "array" (que será un array, me imagino) y "n" que es opcional y por defecto está inicializado en 1. Creas un clon de un array de keys que tendrá el número de propiedades indicada en el parámetro "n", luego con la función map recorres ese array de keys e introduces el primer parámetro "array" en la función randomSymbol.
Realmente no tengo ni puñetera idea para que es ese código, solamente leí tu comentario y tu cita al mensaje 212 XDDDDDDDDDDDDDD
Es probable que me pasa más por este hilo en un futuro, controlo y sé de Angular, pero próximamente empezaré a trabajar con React
pero bueno, poquito a poco.
#219 Haz un console log sin el spread y con el spread y luego vuelve al hilo y pideme perdon.
muahahahahahaha
Estoy fumandome un POC para la empresa, el cliente esta obsesionado en mantener la scroll position en un infinite list, que se carga a medida que te desplazas, y donde los items cargados, si accedes a ellos, son experiencias donde el usuario al volver a la lista perfectamente ha podido estar 20 minutos, asi que mantener en memoria la lista (Provider) no le vale pues al volver ha podido variar muchisimo la data (Problemas de repetidos, missings etc..), tiene que ser fresh data each time.
Y no solo eso, puede volver no dandole a atras en el navegador, sino dandole a un boton de "volver al listado" complicando aun mas el mantener la posicion del scroll, pues es una pagina nueva y no goBack();
Total, que por supuesto, me cae a mi, y he fumado este POC en un rato hoy, mejor no mireis el codigo fuente, pero utiliza el intersection observer.
https://jvidalv.github.io/scroll-position-poc/
Debajo del titulo teneis los parametros que podeis configurar en la url, evidentemente si vais a romperlo lo rompereis, no esta pensado para eso, pero puedes jugar con los items por pagina, paginas etc...
https://github.com/jvidalv/scroll-position-poc
Esto confia en que sabes de antemano el tama;o (Mas o menos) de todos los elementos del listado, el problema es que tenemos mucho masonry que va a dar por culo de forma tremenda.
El team leader por teams despues de que me cayera a mi el muerto:
Que opinais?
#222 Entiendo que los nuevos items (fresh) siempre irían arriba, asi que, puedes mantener el id de más arriba que has visto y el id de por donde vas (si se mantiene siempre el mismo orden). Es decir, deberías ser capaz de decir "desde X a Y ya los has visto" y ocultarlos con un collapse o similar, en plan (esto ya lo has visto...) y cargar por encima y por debajo de este grupo, actualizado first/last conforme navega, si quiere cargar por encima o por debajo de este bloque, se puede hacer fácilmente.
Y depende de cómo ordenes te será más fácil o más difícil hacer las queries.
Cambias tu problema de scroll a feature.
#225 No acabo de entenderte cuando dices que los fresh van arriba.
El problema es el siguiente, es una pagina de scroll infinito, y el cliente quiere que una vez haces click en un item, al volver (Ya sea mediante atras en el navegador, o mediante un boton dentro de la pagina detalle "volver a la lista" ) estes en el mismo sitio.
Al ser una lista de scroll infinito no conocemos de antemano el height de la pagina, asi que el navegador no puede mantener la posicion del scroll.
- Solucion facil y para toda la familia siendo React y NextJs? Un provider comun en ambas paginas (Lista y detalle) de tal forma que al volver atras los elementos aun cargados aun estaran disponibles (Servidos por el provider) y la posicion no se perdera.
Primer problema, la navegacion dentro del detalle puede durar 20 minutos o mas, no es entrar y salir... Entonces, en medio de un SHOW que es cuando se visita esta lista, hay mucho movimiento, elementos que van y vienen, que puede pasar? Al volver atras la lista que tenias guardada este desacualizada, favoreciendo cosas como repetidos (Que se puede controlar facil en el FE) o elementos que han subido de posicion ha paginas que ya tenias cargadas y por ende, no los veras al cargar la siguiente pagina pendiente (Imposible de controlar eso en el FE).
Y aqui aparecio el arquitecto del proyecto, y dijo, si vamos por esta solucion, con estos problemas, nos meteremos en un marron en el BE pues el cliente querra que esto no pase, o se minimize al maximo, los tios en la lista pagan por estar en la lista, no puede ser que haya un posible comprador que no los vea.
Solucion: https://jvidalv.github.io/scroll-position-poc/
Fijate que si vas a la mitad del listado, y recargas la pagina, al volver solo cargaras el sitio donde estabas, y a medida que te muevas arriba y abajo volveras a cargar esas zonas.
Esta solucion conlleva sus problemas, tienes que saber mas o menos que height van a tener los elementos del listado para poder pintar los elementos vacios arriba y abajo, en una de nuestras listas infinitas que es un masonry, esta solucion es problematica y no solo eso si haces scroll super rapido vas a generar muchisimos fetchs por todas las paginas por las que pases.
Otra implementacion seria generar solo n + 1 y n -1 y ir a;adiendo a medida que vas cargando, esta solucion es la que me propuso el arquitecto originalmente, y que creo que intentare implementar ma;ana si tengo un rato.
Lo cierto es que la hice ayer en un rato y se podria afinar muchisimo, por ejemplo, aqui no guardo ni pagina ni elemento en el que haces click, esto me lo guardo para la implementacion real en el proyecto.
No entiendo que es "el mismo sitio", si volver a la página 10 elemento 8, o volver al elemento que has seleccionado
¿El IntersectionObserver es únicamente para páginado?
#227 Volver al mismo sitio donde estabas para poder continuar la navegacion como haces aqui por ejemplo: https://www.artland.com/artworks
Aqui hacen lo que yo haria, meterlo en un provider que no se desmonta siempre y cuando navegues dentro de la pagina (Es NextJs tambien la pagina)
#226 La propuesta de tu arquitecto es más o menos es lo que te digo, al volver atrás entonces, siempre estas en el id del que entraste, y tienes camino hacia arriba (nuevos) y hacia abajo. Un virtual scroll en el que puedas ir tanto hacia arriba cargando los más nuevos y hacia abajo (cargando más antigüos). Al volver atrás, lo que vuelves es a una posición virtual marcada por el item del que vuelves, con que dejes suficiente espacio hacia arriba como para poder hacer scroll e ir cargando hacia arriba, es suficiente. No necesitas precalcular la distancia del scroll siempre que al cargar nuevos por arriba se mantenga el scroll actual, lo cual no se como quedaría, igual haría que fuese un poco clunky.
Me lo acabo de "pillar". Si alguno lo conoce: Merece la pena echarle un ojo en condiciones, o solo de apoyo? or not at all?
https://www.oreilly.com/library/view/learning-react-2nd/9781492051718/
#230 habrá que ver hasta qué punto está actualizado, aún así, como todo, úsalo de apoyo y compaginalo con diferentes fuentes de estudio
Yo en el curro uso angular + .net. Normalmente hasta con .net core veo que angular es bastante común, así que pensaba darle un repaso bueno a angular en casa pero no sé si aprender react en vez de pretender profundizar algo en angular.
Cómo veis el stack? Yo sigo viendo demasiado dotnet core+angular como para pensar en react, pero no sé si alguien tiene alguna opinión al respecto.
Que si estás a gusto con lo que estás, y tu plan de futuro/cambio seguirá siendo .net más la mierda de front que surja en ese momento, mejor disfrutar de otras cosas de la vida.
#234 Esto es el hilo de React ya sabes que te vamos a decir.
Como experiencia personal, yo veo React por todos lados, y cada vez mas, si te enchufas la extension de React Dev Tools que se ilumina cuando entras en paginas que utilizan React esta everywhere.
Y no solo React, creo que React Native esta en una espiral ascendente y suena como substituto a Electron la hora de hacer apps en Windows.
Osea aprender React quiere decir, aprender Web, móvil y desktop todo en una.
#234 Yo te diría que es un stack que está bastante maduro y sinceramente creo que es un gran momento para aprender a usarlo.
#234 Yo como n00b no te puedo comparar con otros, lo que si te puedo decir que viendo los curros por la zona de Amsterdam, por cada oferta de Angular que veo, hay otras 6 o 7 para React, y 2 o 3 para Vue, que está ahí metiendo la puntita también.
#235 yo la verdad que tengo ganas de cambiar pero no sé si me tengo que poner guapo el linkedin (que lo tengo vacío 100%) o que el cv lo tengo mal montado porque la verdad que no me hacen ni puto caso. Por eso quería probar a indagar yo por mi cuenta que, desgraciadamente, siempre aprendo bastante más que en el curro (uno de los motivos por los que me quiero ir).
A mí la tecnología en sí me da igual porque en casa cacharreo con mil cosas distintas pero se ve que la gente pone pegas fácil (cuando con buenas bases el resto da igual).
Igual le doy un tiento a react viendo que hace poco estuve con redux (xd) para una cosilla, y si no para angular ya tengo el check del curro en el CV aunque no haya hecho nada con él.
