[React] Hilo General - Una librería para atraerlos y atarlos a todos

isvidal

#240 Hombre, tu mismo te respondes.

Curate el Linkedin y veras como empiezan a subir las ofertas como la espuma, y al final es como todo en la vida, question de números. Cuanto mas entren, mas posibilidades hay. Y solo hace falta acertar una vez.

Y luego yo en mi CV lo primero que pongo antes de mi experiencia y estudios es un párrafo diciendo, mira, si me quieres conocer lo mejor que puedes hacer es visitar mi pagina web personal, mi Github o mi perfil de stack overflow.

Solo con estas 3 cosas estoy seguro que ya estoy en el 1% de todos los que se presentan a esa oferta, visto el panorama que he tenido de compa;eros de curro históricamente (0 github, 0 pagina personal, 0 stack overflow).

Y al final es una peque;a inversion de tu tiempo que se puede traducir en pillar un muy buen curro (El tener un Github, pagina personal y SO curado).

#239 Mi recomendación personal, o como funciono yo, es sudar de cursos, y plantearte alguna app peque;a chorra que puedas hacer en 4-8 horas y hacerla de principio a final e ir resolviendo los problemas que te salen. Puedes preguntar en este hilo.

1 respuesta
Axtrix

#239 +1 a lo que dice #241 cogete alguna de estas apis y te montas un front tocando lo que puedas de React.

A ver si actualizan la documentacion con los hooks

1
Chorlo

#240 Si te actualizas el CV y tienes más de 3-4 años de experiencia en el sector. Deberían contactarte de vez en cuando. :-). React tiene mucho más curro que el resto de librerías de Front, es el nuevo jQuery.

1
pantocreitor

Por curiosidad, existe algún tuto tipo tour of heroes de angular en react???
Del estilo app chorra para ver un poco estructuras y funciones de todo.
Hice un curso de react de 2 días ultramegachorra en el curro y van a empezar a seleccionar gente para un proyecto nuevo y quiero ir preparándome para cambiarme a ese.

Si no pues haré lo que comentáis, hacer un mini project e ir metiendo cosas aleatorias por ver cómo funciona, pero si es algo guiado no se me pasa nada.

2 respuestas
aren-pulid0

#244
Hazte el tipico listado de productos con un carrito de la compra y un checkout.

Aprende con React.Component, despues pasa a Functional Components y después utiliza Redux.

Al final, necesitaras muchas cosas similar a Angular como el enrutamiento y etc etc... Suertee

1 2 respuestas
VonRundstedt

#244 Justo ahora estaba liado con Codeacademy y en esta lección tienes que trabajar con un carrito de los que menciona #245 por si te interesa.

https://www.codecademy.com/courses/react-101/lessons/the-state-hook/exercises/lesson-review

1 respuesta
pantocreitor

#245 Básicamente ese fue el curso del curro xD
Un pequeño login sin auth, solo comprobar nombre y contraseña a pelo, conectar con base de datos para los usuarios y los productos, lista de productos, selección, mostrar selección y finalizar.

#246 thanks, le echaré un ojo para ver si sigo por ahí o voy buscando algo mas de material.

RQuaza

Estoy buscando curro, y estoy flipando con la de ofertas que hay de angular... Creo que ultimamente ha ido ganando terreno, porque 7/10 son de angular en el front

1 respuesta
Axtrix

#248 Hay que reponer a todos los angular devs que se han pirado de sus empresas para irse a trabajar con React
/s

1 respuesta
RQuaza

#249 jajajajaj, que opinais del seo? angular es tan bueno como dicen?

1 respuesta
Ranthas

Pues precisamente el SEO es algo que en Angular da bastante por culo.

Axtrix

#250 Si necesitas SEO en React y no te apetece reinventar la rueda, tienes Gatsby para generar paginas estaticas o Nextjs para hacer SSR

1 respuesta
MisKo

Buenas !

Otro por aquí que le ha dado por aprender React. He tocado tanto Angular como Vue y estoy migrando una de las cosas que tengo hechas con Vue a React (Con NextJS) para ir probando mientras voy aprendiendo xD

La idea sobre todo de aprender react es luego meterme con react native y hacer pruebas ahí tb, pero eso ya llegará cuando sepa defenderme un mínimo con react xDD

#252 Aunque estoy empezando, creo que para tema SEO, NextJS también te permite exportar los HTMLs rellenos: https://nextjs.org/docs/advanced-features/static-html-export

1 2 respuestas
Axtrix

#253 Primera noticia que tengo, habra que echarle un ojo entonces.

Si a alguno le interesa ya que no veo que nadie lo haya compartido, la semana que viene hay una "conferencia online" de Nextjs https://nextjs.org/conf

MisKo

Aunque llego tarde, en cuanto al tema de mantener el estado general de la aplicación para consumirlo en otros componentes (no se si Redux o Context como habláis, aun no he llegado a ver nada de eso), supongo que será un poco la misma dinámica que en Vuex, por lo que yo si le veo bastante más usos de los que comentáis:

Preferencias de usuario

Como indicáis, tener los datos de usuarios de manera global en la plataforma para consultarlos en cualquier componente. Ya no solo su nombre para mostrarlo en la cabecera, si no preferencias para la app como el idioma, si prefiere ver las cosas con imágenes o no, en modo tabla o modo caja....

Tablas maestras

Si por ejemplo, en lo que desarrolléis, hay una especie de tablas maestras (lista de provincias con sus ids, de categorías, de puestos de trabajo, de tipos de productos...), pues todo eso se debería de cargar una vez y mantenerlo de manera global.

Se consultaría esa información desde cualquier otro componente para rellenar selects, filtros, etc...

Sistema de notificaciones

La típica alerta, como la que tiene mediavida arriba. Por ejemplo, actualizaríamos su estado desde un layout cada X tiempo y la pondríamos a 0 una vez hemos entrado a leer el mensaje pendiente ( desde otro componente )

Loading

Al igual que con las notificaciones, podriamos tener un "popup" de loading para mostrar al usuario que estamos haciendo algo y que espere. El estado del popup (activo o inactivo), se podría setear desde los componentes. En el layout global, comprobaríamos su estado para mostrarlo u ocultarlo en base a dicho estado.


Como he dicho, estoy empezando con React y estas opciones vienen más de la experiencia con Vuex , pero creo que se podrían aplicar a Redux o Context, aunque lo mismo cuando lo vea funcionan bastante diferente o tiene otra manera de encargarse de estas cosas xDDD

2 respuestas
Zoko

#255

No veo lo de las "Tablas Maestras" la verdad, por que ibas a ensuciar el estado global con estos datos cuando puedes simplemente importar el módulo de JS conteniendo los datos cuando lo necesites?

1 respuesta
isvidal

#253 Sobre el tema de SEO.

SEO EN REACT

Empezando por lo básico, al ser REACT ejecutado en cliente cuando el crawler de Google pasa se encuentra una pagina en blanco, pues el JS que genera el HTML no tiene preparado el documento al instante.

Dicho esto se supone que Google tiene dos tipos de crawler, los que van a toda ostia y no se esperan a nada, y los que si se esperan, por tanto, si no te pilla el primero te debería pillar el segundo. Dicho esto, se recomienda que siempre te pille el primero.

Aun así, en React puro tienes problemas con los tags de las paginas que puedes salvar utilizando React Helment.

Bien, entonces que hace NextJS o Gatsby, Gatsby directamente genera el HTML que tu subes al servidor, de tal forma que cuando el crawler llega ya se encuentra el documento montado.

Y NextJS? Bueno, NextJs te ofrece absolutamente todas las opciones, desde la misma que React vanilla, servirte la pagina desde el servidor como si un PHP se tratara, o un mix entre ambas.

Por eso si el SEO, navegación son muy importantes, yo recomiendo siempre tirar por NextJs O Gatsby o similares.

Hay una libreria para React vanilla llamada React Snap, que basicamente saca una foto html de tu pagina, y sirve ese html mientras el JS carga, de tal forma que el crawler pilla cosas en su primera pasada.

#255 Sobre el contenedor de estados

Gestión de estados, utilizando createContext, useReducer y exponiendo la data con un hook custom

Vaya por delante que createContext, useReducer son API's nativas de React (No hace falta Redux). Voy a poner un ejemplo de una APP con React Native que estoy desarollando en mi tiempo libre para una empresa constructora, esto es el entry point de la app:

Y creo que justamente definen muchos de los puntos o tipos que has usado.

Para los que no estén tan versados, eso que ven allí, excepto

<Core />

son providers, es decir, almacenan un estado, el cual puede ser consultado y modificado por todos sus descendientes, de tal forma que no hace falta ir uno por uno.

Empezamos por el primero:

<AppearanceProvider> : Almacena todo lo relacionado con los temas y estilos de mi aplicación.

<UserProvider> : Almacena la información relacionada con la session de usuario, esta logueado o no? Utiliza el tema oscuro o blanco?. Luego expongo esta información con un hook custom (useSession) con las siguientes propiedades, de tal forma que nunca tienes acceso directo al provider, sino que tienes que pasar por los métodos que yo defino:

return {
    session,
    dispatchSession,
    isLoading,
    isThereAnError,
    signIn,
    signOut,
    getLocalSession,
    setLocalSession,
  }

<DataProvider> : Aquí se guarda toda la información crucial para el funcionamiento de la aplicación (Que se recupera de la API cuando el usuario abre la APP), es decir, listas de cosas que se necesitan para mostrar la información, en este caso aquí guardo: Clients, Constructions, Materials. Data que luego uso para llenar selectores o para mostrar el nombre del cliente en lugar de su id... Como quiero que este provider sea lo mas funcional posible, no tiene declarado ningún tipo (Que podría), y expongo su información con un custom hook (useData) con las siguientes propiedades:

return {
    getData,
    setData,
    getItemInData,
    getItemsInData,
  }

Estas propiedades me sirven para todos los tipos, quiero almacenar una data nueva? setData(arrayDeObjetos), quiero recuperar toda la data? getData(), quiero solo Clients? getItemsInData('Clients'), quiero un item con id 12 concreto de clients? getItemInData('Clients', 12).

<SnackbarProvider> : Esto es el generador de avisos, cuando se setea muestra una barrita en la parte baja del móvil a lo google para decirte que "Bien has creado un parte de trabajo" o "Mal, tus datos de usuario son erroneos". Y expongo su funcionalidad con (useSnackbar):

return {
    snackbarProps,
    add,
    dismiss,
  }

De tal forma que el a;adir un aviso nuevo, o eliminarlo o acceder a las propiedades del snackBar actual es claro y cristalino.

Los otros dos restantes, SWRConfig y ListProvider son para otras cosas que no vienen a cuento, pero se pueden imaginar que hacen.

11 2 respuestas
MisKo

#256 No entiendo lo de "importar el módulo de JS", igual es algo de react xD (no lo de importar, que eso es de JS xDDD).

De todas formas, lo de tablas maestras creo que es realmente uno de los usos básicos de estado, por eso no entiendo lo que comentas de importar el módulo de JS xD

Creo que con los ejemplos de #257 se explica mejor lo que comento yo xDD (por lo que he leido, porque viendo solo el código, poco xDD )

1 respuesta
aren-pulid0

#257 De 10 la parte de gestión de estados, se merece sticky, y lo de seo también muy interesante

Axtrix

#258 Depende mucho de los datos que uses y cuantas veces lo use. Yo una lista de provincias para popular un dropdown no lo meteria en un state, lo cogeria de una API o las vagas me guardo un JSON en el projecto y a correr.

1 respuesta
MisKo

#260 Si, eso está claro. Si solo lo usas en un componente, pues lo recuperas en ese momento vía API y listo, pero si lo estas usando en muchos sitios (en un proyecto que tengo, se utiliza fácilmente en 20 / 30 sitios distintos la lista de provincias), es necesario tenerlo en algún sitio centralizado.

De todas formas, quiero saber lo de importar un módulo de JS que decía Zoko, lo mismo la mecánica es la misma y es más eficiente.

1 respuesta
Axtrix

#261 Pero una lista de comunidades autonomas no va a cambiar nunca, si solo tienes un array de strings yo lo meteria en un archivo y cuando me haga falta lo importo, así me quito la complejidad de tener que estar llamando al estate.

Ahora si lo guardas como [{id: xxx, value: 'xxx'},...] y necesitas tener las ids para algo pues si puede que tires de state

Lo de importar un modulo

// comunidadesAutonomas.js
export const comunidades = ['tenerife', 'madrid, ...]

//miFormulatio.js
import {comunidades} from "../../ruta"
1 3 respuestas
MisKo

#262 Si, las ids las necesito para las relaciones en la ddbb, pero en tu ejemplo también se podría guardar las ids en JSON y no pasaría nada.

Básicamente, como tengo las provincias ya en la ddbb (por tema relaciones), prefiero hacer la call a la API para traerlas que tenerlas en un JSON aparte. (casi nunca me ha convencido tener esas cosas en un json, salvo que no haya una ddbb detrás, la verdad xD)

Acabo de ver tu edit.

¿Qué diferencia hay en tener eso en un archivo e importarlo así, que tenerlo en el state?
Supongo que no lo tienes en memoria hasta que lo cargas en el propio componente y que se quitará de memoria una vez se destruye el componente, no? xD

Y si dentro tienes que traer los datos de una API, ¿lo traería siempre que haces el import?

Zoko

Efectivamente, #262 tiene la clave en cuanto a lo que yo me refería.

2 respuestas
MisKo

#264 #262 De todas formas, creo que el tema viene más por aquí: así me quito la complejidad de tener que estar llamando al estate

Como no lo he visto aun en React, no se como de difícil es.

En vue con this.$store en cualquier sitio ya tienes el acceso, por ejemplo this.$store.state.provincias y listo, sin configurar nada más xD

2 respuestas
Zoko

#265

No es que sea complejo, es que es una guarrería tener que acceder al estado para coger una lista estática de algo :/
El estado está precisamente para cosas que cambian.

2 respuestas
isvidal

#264 Si, pero no puedes hacerlo con data dinámica de una API, el ejemplo en mi ejemplo: Clients, Materials, Constructions, son dinámicos, los necesitas tener almacenados en algún lado, y no solo eso, provincias aun estáticas, si también las tienes almacenadas en BD y utilizas su ID para mi es una guarrada tenerla duplicadas en un .js.

#266

El estado está precisamente para cosas que cambian.

That's not true at all. Es decir, si y no, evidentemente SI NUNCA cambia, es decir, cuando enciendes la app ya esta allí, y nunca cambia entonces OK. Pero algo que no esta al principio, pero luego (Recuperada de la API) hasta que la cierres si esta, para mi tiene todo el sentido del mundo.

#265 El this no existe en React funcional utilizando hooks. Defines un provider, defines su hook de acceso,

Primero creas el contexto:

export const StateContext = createContext(intialState)

Luego creas el hook que te permite acceder a el en cualquier lado

export const useProvider = () => useContext(StateContext)

useProvider devolverá un array donde en la posición 0 tendras el state y en la posición 1 tendrás el dispatch para lanzar acciones en el reducer.

Asi que si en initialState tienes { apple : 3 }, para acceder a apple en cualquier lado de tu app haces: const [{ apple }] = useProvider()

1 1 respuesta
MisKo

#266 Con el ejemplo que estamos usando (lista de provincias) podría valer lo que comentas (que no cambian), pero si tenemos una lista de categorias o de productos que el usuario puede gestionar, eso ya lo meterías en el state?

Tampoco quiero dar por saco con el tema, que a veces soy pesado con lo mismo, pero asi me entero bien todas las opiniones que teneis de esto (que se podría extrapolar a cualquier tecnologia, no solo a Redux)

#267 Si, lo del this es el ejemplo en Vue, yo lo que estoy tocando en las pruebas de React lo estoy haciendo todo con funciones (nada de clases). De todas formas, todo lo que comentas me sirve para aprender xDD

2 respuestas
isvidal

#268 Yo discrepo un poco con que la data en los estados debe ser siempre dinámica. Evidentemente la data en un estado común, esta allí pues es posible que cambie en algún momento, pero eso no quiere decir que no tenga sentido almacenar data "estática" que se carga una vez y se deja allí como por ejemplo Provincias que vienen de una API.

Me parece mas limpio y mas manejable que la alternativa que es, o bien llamas a la API cada vez que la necesites, o bien lo guardas en en el dispositivo con LocalStorage o con AsyncStorage.

Es decir, cambiara la data de Provincias una vez abierta y cargada la app? No, pero si viene de una API y es utilizada en muchos sitios para mi tenerla en un provider común es un must

Axtrix

#268 Cada caso de uso es diferente y ninguna opcion es incorrecta, cada uno tiene que ver que cosa le conviene más y le va a dar menos por culo en el futuro.

La putada del estate es que todo lo que use el state se va a re-renderizar si cambias cualquier cosa (cosa que con redux no pasa). Yo guardaria solo el usuario, preferencias y poco más.

Yo lo pediria todo de la API al final (las categorias y productos si el ususario las puede gestionar a lo mejor otro ususario tambien puede y los datos de tu BBDD van a ser diferentes a los del estado local)

Si tienes algun ejemplo mas especifico pasalo y a ver que dice la gente del hilo

P.D: @isvidal que te parece ir añadiendo librerias utiles a #1 yo he empezado a usar https://react-hook-form.com/ y no vuelvo a picar un formulario a mano

1 2 respuestas