bitfocus
Identify all actions / feedbacks / variables from a connection in use
Is this a feature relevant to companion itself, and not a specific module?
- [x] I believe this to be a feature for companion, and is not specific to a module
Is there an existing issue for this?
- [x] I have searched for similiar existing issues
Describe the feature
With large configurations (in terms of connection count, and page count) it can be difficult to remember or identify all locations using resources from a connection. This is especially likely to be the case when multiple team members have all contributed to different sections of the companion config over the course of time.
When performing large system changes its can be important to identify all relevant resources of a connection. For instance to migrate to a new device/connection, or verify that a connection is no longer needed before removing.
At the moment the only feasible way to do this is to export the config and then open it in a text editor and use the search function.
This was discussed in this thread on slack.
It is understood that given the potential for nested variables returning an accurate list (or even any list) of variables in use may be fraught.
Clearly this would require some UI design work, and I am not certain what the best implementation would actually look like - but my current thinking is a list of action/feedback instances access from the connection menu button (similar to window of variables). Where each action/feedback/variable has a link to take you to the relevant button or trigger.
Usecases
More practical and safer long term maintenance of large configurations.
My immediate thoughts are that this could be something accessed from the connections page, in the ... menu for each connection.
I dont know whether it would be better to group here by the action/feedback type, or to do so by location. maybe it should be possible to handle both?
Then I guess for each we should be able to show:
- The type of the action (eg 'System: Run shell path (local)`)
- The user defined 'headline'/label if any is set
- The location of the action, ideally down to the action set (eg, 1/0/2, Step 1, Press)
It should either be possible to click on one of the actions/feedbacks and jump to the correct page it is in (or as close as we can get), or maybe it would be worth this page being in the two column layout and for clicking on an action/feedback to open the corresponding button/trigger in the right panel.
As for variables, we can probably try to do the same, but with a clear warning that this isnt guaranteed to be everything, as some references can be constructed dynamically so we cant detect them.
I suspect that this page will want to load data once with an option to manually refresh the data. Purely because finding all these references is going to involve actively searching through everything, so we cant easily do it reactively and dont want to be running it unnecessarily
If we want to get really fancy, maybe we should be able to track when variables are used and by where; so that any dynamic references get reported upon use instead.
Maybe this should be its own page, just to monitor variables being parseed in the system (with the option to filter by label)
I think this is more of a UX/frontend challenge than backend. Writing the logic to perform the search is fairly straightforward; we are already doing similar searches at other times.
Having said that, it would be nice (but not essential) to do some reworking of the backend to handle this better and be able to provide reactive updates; we already do this to inform the connection about the actions and feedbacks it is running, so with some refactoring it should be possible to rework those updates so that this usage page can hook into the same data.
We don't have anything similar for variables, so that might would want some deeper thought on how to make reactive.
My immediate thoughts are that this could be something accessed from the connections page, in the
...menu for each connection.
That was exactly my (not very clearly articulated) thought.
I dont know whether it would be better to group here by the action/feedback type, or to do so by location. maybe it should be possible to handle both?
I think both would be ideal.
Then I guess for each we should be able to show:
- The type of the action (eg 'System: Run shell path (local)`)
- The user defined 'headline'/label if any is set
- The location of the action, ideally down to the action set (eg, 1/0/2, Step 1, Press)
It should either be possible to click on one of the actions/feedbacks and jump to the correct page it is in (or as close as we can get), or maybe it would be worth this page being in the two column layout and for clicking on an action/feedback to open the corresponding button/trigger in the right panel.
If the latter were possible ( a two column layout where the action or feedback could be brought up in RHS panel) that could greatly speed up things, vs having to go back and forth many times to check/change possibly hundreds of actions & feedbacks. Ideally, I think, for context if the right column could show the full properties of the button or trigger just like the normal editor. Im thinking here that I have some buttons with 6-8 feedbacks on them, some of which dont change any button properties but exist, for instance, to make an ember+ connection subscribe to a parameter, and being able to see these in the context of the full button config makes them a bit less abstract.... or I need to be more on point setting headline text.
As for variables, we can probably try to do the same, but with a clear warning that this isnt guaranteed to be everything, as some references can be constructed dynamically so we cant detect them.
I expected as much and I think a reasonable best effort is better than nothing.
I suspect that this page will want to load data once with an option to manually refresh the data. Purely because finding all these references is going to involve actively searching through everything, so we cant easily do it reactively and dont want to be running it unnecessarily
Given its likely to only be used occasionally during maintenance periods, I think a manual refresh is ok. But then, maybe others will find use for it also?
If we want to get really fancy, maybe we should be able to track when variables are used and by where; so that any dynamic references get reported upon use instead. Maybe this should be its own page, just to monitor variables being parseed in the system (with the option to filter by label)
This reminds me of something else Id love to see.... a read only last fired property for actions, and last changed property for boolean feedbacks.
I think this is more of a UX/frontend challenge than backend. Writing the logic to perform the search is fairly straightforward; we are already doing similar searches at other times.
Having said that, it would be nice (but not essential) to do some reworking of the backend to handle this better and be able to provide reactive updates; we already do this to inform the connection about the actions and feedbacks it is running, so with some refactoring it should be possible to rework those updates so that this usage page can hook into the same data. We don't have anything similar for variables, so that might would want some deeper thought on how to make reactive.
will shoot you a message on slack re: needs beer.