Reduce the usage of the global state in vuex

[christianlupus]

Hello @MarcelRobitaille,

I wanted to ping you related to another topic: currently wow some data is exchanged by means of the global state in Vuex. With respect to put discussion related to frontend testing, the global state will make these tests more complex.

So, i suggest that we rework the structure accordingly when preparing the frontend migration of the app in #1244. During that, a major update is needed anyway. Then we might as well fix some of these flaws is possible and appropriate.

I just wanted to ask you for your general opinion on this. Of course, others can discuss as well.

[MarcelRobitaille]

I am always for reducing global variables. Do you have some proposals on how to execute this? It's my understanding that adding to the global Vue object is the canonical way interface with plugins.

[christianlupus]

The Vuex is feasible for real global information like configuration information and login information.

I was already considering putting the current recipe into the props section of a parent Vue component that will pass that (or parts of it) to all sub-components. Changing the values must be handled vis events in this case.
It might add a few more lines of code to handle data up and down the Vue tree. However, this will reduce the number of global variables used in the complete project.

I do not like if this is considered the standard way to handle such data with plugins but do we have any such plugins in use? I thought we are running a more or less raw Vue component. I am more concerned with the Vuex store.

I am considering having in the three columns layout each column a separate component. The middle component will emit an event upon the selection of a new recipe with a payload of the recipe (stub). The right component will then load that and show its content. It will pass e.g. the instructions to a component that shows just these instructions.

I just wanted to avoid you start implementing things and we have to refactor that soon after.

[MarcelRobitaille]

Maybe I misunderstood this discussion. I should have read more carefully. We do have some plugins like that. I thought maybe my adding logging had prompted this, as the logger adds itself to Vue.$log. We also add showdown and modal dialogs like that. So not a huge amount of plugins, but some.

[christianlupus]

All right. We seem to talk about different things. With Vue 2 some things like Vue plugins are always statically included. This is nothing I would worry about for now. With Vue 3 this is different though.

I am more concerned about the Vuex store. This contains for example the current recipe to be edited or viewed. This is for sure some sort of state but not necessarily the global state. This would IMHO be better placed as props of RecipeView. There, we have to monitor both the local state and the store to keep things in sync. That would manage Vue for us if we let it do its job.

When thinking of visual testing, the global state in the Vue store might cause some issues and might be better if replaced by local parameters and variables. Then, the components can be tested individually (hopefully no other dependencies are there).

[seyfeb]

I agree, just one thing to mention: If we have, e.g., a navigation bar which is not part of the RecipeView, but is also showing, e.g., the name of the currently edited recipe, this has to be kept in sync which is currently done by using the same state (if I remember correctly).

[christianlupus]

Yes, that is true. These components needs to be notified of the new recipe name.

Here i suggest to use the event bus. We could even consider using an external event bus as Vue 3 will not have one on board (but the nextcloud event bus will provide an alternative though). Then, such events can notify other components of such events.
Alternatively, one could consider other means like portal-vue: see here for example.