¿Cuál es la diferencia entre el estado de la aplicación y el estado local del componente en Clojurescript Om?
(1)
He pasado por el tutorial básico de Om de David Nolen, pero todavía estoy un poco confundido acerca de la diferencia entre el estado de la aplicación y el estado local del componente. Cuando se hace referencia a los cursores, ¿se está refiriendo también a uno o ambos?
Como yo lo entiendo:
El estado de la aplicación es el estado "global" al que pueden acceder todos los componentes en el árbol de componentes, a través de los cursores. Este es el estado en el que se encuentra su aplicación y, básicamente, lo que Om está dando. Entonces, por ejemplo, si está escribiendo un programa de chat, el estado de la aplicación contendría una lista de usuarios en la conversación y todos los mensajes que se han enviado, o lo que sea.
El estado local del componente es el estado que es local para un componente único y no se puede ver fuera de este componente. Se establece pasando {: init-state} para compilar, o implementando IInitState y devolviendo un mapa desde init-state - o ambos (en este caso, se combinan juntos). David Nolen recomienda que el estado local solo se use para el estado transitorio, como si el mouse se encuentra actualmente presionado en un componente de arrastrar / soltar y que el resto del estado debería ser el estado de la aplicación. Es decir, si tiene un widget de pestañas, la pestaña seleccionada actualmente debe establecerse en el estado de la aplicación (¡no en el estado local!), Pero si la pestaña se arrastra a una nueva ubicación, la posición actual y el estado del mouse serían (temporalmente) hasta que se complete la operación de arrastre) se almacenará en estado local del componente. Cosas como los canales core.async también se pueden almacenar en el estado local (aunque también los he almacenado (y visto que otros hacen lo mismo) en estado compartido y en datos adicionales; vea a continuación para obtener detalles sobre ambos)
Los cursores solo se aplican al estado de la aplicación y son como ventanas para que los componentes situados muy abajo puedan acceder solo a los datos a los que realmente necesitan acceder.
El estado de la aplicación siempre se accede a través de un cursor ( aplicación en el tutorial) y la modificación del estado de la aplicación se realiza a través de un cursor, ¡ambos om / update! y om / transact! tomar un cursor como su primer argumento. ¡También puede configurar el átomo de estado de la aplicación directamente con el restablecimiento! y swap !, pero David recomienda no hacerlo ya que al hacerlo pierdes algunas de las características más avanzadas de Om (como ser notificado de cambios en los deltas).
El estado local se puede recibir a través de IRenderState o accediéndolo directamente con om / get-state. ¡Puede establecer el estado local con om / set-state! y om / upate-state !. Los tres toman un objeto de respaldo de componente ( propietario en el tutorial).
También hay un tercer tipo de estado en Om: estado compartido. El estado compartido se pasa a om / root usando la opción {: shared ...} y se puede acceder desde cualquier componente en el árbol bajo esa raíz, usando om / get-shared. La diferencia entre esto y el estado de la aplicación es que el estado de la aplicación se reduce a través de las rutas del cursor, es decir, los subcomponentes pueden no tener acceso al estado completo de la aplicación, mientras que el estado compartido siempre es accesible. Además, la modificación del estado de la aplicación hace que el componente se vuelva a procesar mientras que el estado compartido no desencadena los renders.
Como un lado, en realidad también hay un cuarto tipo: puede pasar datos adicionales a los componentes a través de la compilación usando la opción {: opts ...}. Se trata de datos que viven fuera del ciclo de vida de Om / reaccionar, es decir, datos inmutables a los que se puede acceder desde un componente, pero el componente no lo gestiona de ninguna manera. Esto parece ser más útil para los datos de configuración.