search

FlowFuse / flowfuse

Connect, collect, transform, visualise, and interact with your Industrial Data in a single platform. Use FlowFuse to manage, scale and secure your Node-RED solutions.
https://flowfuse.com
Other
281 stars 63 forks source link

Centralise instance status storage #1991

Open Pezmc opened 1 year ago

Pezmc commented 1 year ago

Description

Currently, individual sections of the frontend codebase maintain their own copies of the state of various objects, including the instance details and current status.

This means that when navigating from /team/applications to /application/:id for example, a new request is made to the server to load all of the instances and their states, despite it already being in browser memory from the /team section. This same anti-pattern applies to many loaded objects (applications in team, instances in application, devices in team), etc...

Instance status seems a good place to start to experiment with storing more state in the existing vuex state store (or migrating to the replacement pinia) to improve the snappiness feel of the app.

This would be part of a proposed wider re-design of the front-end code to store state for important objects inside of vuex state management, rather than loading it multiple times throughout the app.

The store would be updated store all loaded instances, and would maintain this cache, when a page asks for a copy of an instance, the store can return the cached state, and in the background fetch updates, making the page feel much responsive to the end user.

This can be extended further, to moving all CRUD events for instances to go through the state management; keeping them in sync throughout the frontend; and improving code reusability, ease of maintenance, and reducing duplication.

Epic/Story

No response

Pezmc commented 1 year ago

@joepavitt @knolleary Would appreciate some thoughts here, both on experimenting with this for instance status; and for moving the wider codebase to make more use of vuex

joepavitt commented 6 months ago

@cstns just working through some old issues and noticed this, which reflects a lot of the same thinking you've shared.

cstns commented 6 months ago

Very well written and explained. The tricky part is how to break the entire functionality into smaller deliverable pieces and coming up with a store design that will adapt to the application flow while being scalable.

One beneficial side effect of this will be the separation of representational functionality from core functionality, allowing us to properly unit test the frontend application in a cohesive manner.