En estos casos suele ser por alguna mierda de cache del navegador, te recomendaría varias cosas:
Si con esas 3 todavía sigue pasando abre un PR a React porque es 99.99% imposible que te ocurra.
#90 SI se esta renderizando el componente debería ser un bug.
Podrías utilizar Memo o Profiler para ver que esta pasando.
https://brycedooley.com/debug-react-rerenders/ (un articulo rápido para que tengas algo más que la documentacion)
#93 Sorry, se me fue.
La verdad es que se fue como vino, yo estaba haciendo cosas raras que no se deberían hacer con context y tal, pero sigue sin explicarse lo que paso allí, o porque me dejo de tirar los hooks dentro de ese componente. Al final actualizando, ctrl f5, cambiando código funciono.
Era muy fuerte porque ponía console.logs fuera del React.useEffect y se tiraban, pero los de dentro no, osea no es que estuviera algo cacheado a muerte, pues los updates de código al componente los pillaba con el hot reloading.
He de decir que esto es un puto NextJs version 8 tuneado por donde han pasado 30 indios así que digamos que va un poco como el puto culo. Por suerte me han dado confianza asi que estoy refactorizando a muerte, ya he pedido subir la version de Redux para poder utilizar hooks y no tener que usar el connect, y luego pediré si me dejan subir Next así alomejor mejoramos algo el performance en desarrollo que la version 9.4 mejoraba mucho esto.
Pero ya te digo, el codebase es un tru;o tremendo, el senior ya me dijo que estaba encantando que yo refactorizara y hiciera cosas nuevas, que ellos solo copiaban y pegaban que ya eran viejos jajajajaja
Hijos de perra, son seniors por viejos y no por buenos jajajaj
/rantoff
buenas, que me podeis recomendar para una entrevista? he pensado en preparar un portfolio con algunos de los proyectos que se hacer... como dato, soy junior, manejo el stack mern
En #1 tienes:
https://github.com/sudheerj/reactjs-interview-questions
Que aunque está algo desactualizado no viene mal leertelo y tener claros los conceptos que puedan salir por ahí.
Mostrar proyectos que has hecho tú sin que te los hayas mandado (es decir, no cuentan prácticas de la Uni) es un gran paso para distinguirte de otros candidatos. El saber hablar de por qué hiciste X o Y en tal sitio porque te has peleado con ello les dejará ver que sabes de lo que hablas y que no simplemente sabes seguir tutoriales de React.
Por curiosidad, para qué empresa es?
Una pregunta, como organizais las llamadas a la api?
Es decir, teneis una clase ya sea con axios o fetch, que tenga métodos estáticos o un archivo con funciones de llamada a la api?
Me toca hacerlo en el proyecto y me gustaría que fuese lo mas sencillo y simple posible
#97 Siempre tener todo en una función que te haga la petición con la configuración que tu lo digas.
De esta manera puedes iterar para error handling para todas las apis.
#97 Depende.
Si hablamos de definir los endpoints, si están muy bien documentadas rollo swagger, directamente pongo el string de la url en el sitio donde se use, sino, creo un fichero de constantes y las defino alli con sus explicaciones, parámetros etc...
Luego si hablamos en como hacemos el fetch, bueno, lo mejor es tener instanciado un método re-utilizable en toda la api, de tal forma que encapsulas toda la logica alli dentro (Ejemplo, logear errores de peticiones). Para esto suelo utilizar Axios y últimamente me he enamorado de SWR (useSWR), y en lugar de configurarlo en axios, dejo el axios lo mas simple posible y dejo a SWR que se encargue de capturar los errores y gestionar la lógica común (SWR encapsula Axios, o Fetch o el ""fetcher"" que le pases).
#97 Puede sonar a putisima mierda, pero tirar por código autogenerado es un ahorro de tiempo en general. Si la API tiene swagger y lo expone bien, tienes autogen que no es basura del todo y se puede usar. Después metes capa de abstracción y mapeo si necesitas objetos y tal y tal. Evitando por eslint que se use el autogen fuera de esta capa.
Archivo con funciones de llamada a la API en general, obviamente reusando la lógica de llamar y extraer datos y error handling.
En Angular (aunque es extrapolable al 100% a prácticamente cualquier librería) lo que hago es lo siguiente
Hay un servicio que se encarga de hacer las llamadas de manera abstracta. Este servicio recibe la URL, parametros, body, etc..., lanza la llamada, gestiona los errores (si los hay) y devuelve la respuesta. A este servicio le da igual a qué API llama, que respuesta recibe y demás.
Hay N servicios, tantos como necesites según el negocio, que se encargan de generar los datos para llamar a la API (estos servicios saben a qué URL llamar, como construir las cabeceras, como construir los parámetros, el cuerpo de la petición, saben que respuesta deben recibir, etc).
De esta manera, te ahorras repetir la lógica de llamar a las APIs, te aseguras de que el control de errores es el mismo (aunque en Angular esto lo gestiono con interceptores), tienes las trazas en el servicio central lo que facilita la depuración, y por otra parte, te aseguras que el resto de desarrolladores usan esta arquitectura, ya que los tests se lanzan usando este servicio.
He metido en apuros al dise;ador hoy con el puto SWR, eso de que cambies de tabs y de filtros y te cargue instant debido al cacheo que lleva huuuu
Estoy dudando en hacer un refactor al proyecto opensource antes de lanzarlo. Actualmente uso MongoDB para la base de datos y mongodbClient pero muchas veces me dan bastantes problemas y se me queda como alelado la conexion con mongo y le veo bastantes problemas.
Como la web no tiene demasiada logica de logica y api estaba considerando cambiar el sistema de base de datos y unos cambios que son estos:
Utilizo NextJS y API routes para el backend y esto no quiero cambiarlo.
Estoy dudando muchisimo y ando aprendiendo un poco de todo esto para saber donde me meto, porque con mongo lo tenia como middleware en el servidor para la autentificacion de los endpoints, pero no tengo ni idea como se hace eso con graphQl o prisma 2 la verdad.
Me voy a marcar un triple post y @Jastro no podra hacer nada al respecto.
Referiendome a #104 al final pondre una capa de GraphQL con Apollo server o Graphql yoga junto graphql shield para administrar las queries con un jwt.
Y vengo hacer un poco de "rant" rapida.
La gente que hace prop drilling con "...props" me cago en su totalidad como programador eso y espero que se tuercan el tobillo con muchas esquinas.
En la mierda de antecesor del formik, react-redux-forms y en la absolutisima librería innecesaria que es immutableJS.
Gracias por leerme, besis.
#106 immutableJS esta mas muerta que Angular
Y sobre el resto, cada vez que leo react-redux-whatever, me entran escalo-fritos de abstracciones y fumarolas dignas de la elección de un papa
#107 Tengo un proyecto que hago boyscout quitando immutablej pero hay como 2 zonas de la web que es jodidamente imposible y es horrible.
Me pasa lo mismo con las "grandes librerias" react-redux-tuputamadre-en-almíbar son generalmente hechas por monos.
#106 ¿En serio hace falta una librería para asegurar la inmutabilidad de los objetos en una aplicación?
Me quiero morir.
#109 Cuando la gente no sabe programar inmutabilidad en JS si. Lo cual significa que eres un poco mierder xD
#111 Es shallow, pero debería valer para tipos básicos. Lo de react-redux-* morirá con redux y tal como esta el panorama....
El otro día un compañero se fue de vacaciones y le metieron react redux porque los devs de cliente no entendían los hooks.
#111 Al final si tienes un poco d idea del spreading y del destructuring es la mejor herramienta para mantener inmutabilidad en JS. Ademas de no editar putas propiedades de objetos de un contexto mayor en funciones internas xD
#114 Luego es un poco más complicado si tienes clases de Typescript por en medio, arrays y tal, pero todo tiene solución.
#115 Complicado?
Literalmente Typscript en spreading no debería meterse ya que tienes tipadas las variables entrantes pero el output es diferente.
Por otro lado si en casi que estuvieses modificando arrays deberías hacerla logica fuera y sacar el output y meterlo en el spreading o ejecutar la funcion dentro del sprading. Separar bien la logica es muy util al final del dia.
En otro orden de cosas.
Creo que sería interesante un post / hilo con el stack de libraries que usan para React. Rollo este hilo.
Cada vez le veo más ventajas a React respecto a Angular de cara al día a día, y me gustaría tener un poco más de info de mano de gente que lo use "de verdad" en el día a día.
#118 https://github.com/enaqx/awesome-react Angular tiende a embaucar con sus "buenas practicas" para que no salgas de ahí, metiendo todo en el scope de Angular. Yo soy más de rendering fw: react/preact y behavior/store: en "vanilla" typescript
#118 Dinos que te interesa saber al respecto de Librerias, osea que tipo de librerias y te podemos decir algo mas. Es que s ino es algo muy extendido.
