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

#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.

#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()