Managing usages
Last updated
Last updated
The elements of an app (actions, components, state variables) can be used in many different places. For example, actions can be used in event props of components, could be triggered from within JS actions, or their properties might be accessed in any other component props or actions. State variable values could be accessed in any component property as well, or might be modified in JS actions using the exposed setter functions. Such usages could be not very obvious - they might occur in JS transformations of actions, or could appear in nested properties, like for example a table column or an input validation rule.
Keeping track of these usages becomes very difficult the more complex the app becomes, and applying changes to an app - like deleting things, or changing signatures / structures - hence could break app functionality. This problem exists in traditional engineering as well, and is beautifully solved with sophisticated IDE features for tracking usages of files, modules, objects and variables. The Uify app editor provides similarly powerful features to make usages transparent, and to prevent harmful modifications. This significantly increases the robustness of applying changes, and gives peace of mind while maintaining apps that are used in production.
Our app editor constantly keeps track of usages in various places where code can be used. The result is a sophisticated dependency graph, which allows us to make usages transparent and to dispatch warnings for potentially harmful modifications.
Whenever there is an attempt to delete a component, action or state variable that is used anywhere in code of the application, a warning is shown before such actions will be performed:
In this example, the value of textInput1 is used on the value property of text3. In case this input was deleted, we would end up with an erroneous script in this property of text3, which could be devastating for the correct functionality or usability of this app.
To prevent such mistakes, a warning is shown in such cases, which provides a hint for how often, and where exactly, the particular component, action or state variable is used. The user can then make use of this information and check whether the deletion should really be followed through.
It is possible to ignore this warning and to perform such deletions anyway, this however will most likely lead to broken application logic.
Every component, state variable and action is able to display all of its usages across the entire application. This option is available in the context menus of actions and state variables, and in the menu that appears when right-clicking on a component on the canvas:
The resulting popup visualizes a hierarchical view of all usages of the particular entity:
The code editor on the right-hand side allows to modify these usages immediately, without the need to navigate to the original place of use manually. A larger example of such a usages overview might look like this:
As you can see, usages within the same component, action, or state variable, or even within the same property, are grouped together for convenience. This overview makes it very easy to understand the dependencies of different entities with one glance, and even to modify them in-place.
Despite the ability to modify usages immediately, you might want to rather jump to the original place where the usage occurred. This is possible by clicking on the icon in the top-right corner. The popup will close and the app editor will navigate the user to the place of usage, which can have multiple implications:
If the usage occurs in an action, the action editor is opened and the particular action is selected. In case the usage occurs in another tab than the default, e.g. in a JS transformation, the tab is switched accordingly.
If the usage occurs in a prop of a component, the component is selected, the properties panel on the right-hand side is opened and scrolled to the exact place of usage.
If the usage occurs in a state variable, the explorer tab on the left-hand side is opened, and the edit-view of the particular state variable is opened.
If the usage occurs in a nested property, like a table column or a validation rule, the nested property popup is opened accordingly.
Regardless of the place, the text selection will always highlight the exact usage, and the code editor will be scrolled to the right position so that the usage will be in view:
Changing usages on the right-hand side of the usages popup is a very convenient option, however works slightly different depending on the type of usage.
1. Event properties of components
Event properties, like for example the "On click" property of a button, allow the user to select an action from a dropdown. The selected action will be executed when the related UI event occurs. This is in fact an important usage of an action, however does not involve any code. For that reason, the same dropdown is displayed in the usages popup as well:
Changing the selected action will immediately change the configuration and will be persisted - same behavior like when this property is changed directly in the component properties panel.
2. Usages in action code or state variables
Action and state variable code can be adjusted in-place. However, those have a different persistence mechanism: While changes to component properties are saved instantly, saving actions or state variables is a deliberate user action, making use of a "Save" button. To not mix approaches, the code editing in the usages popup follows the same principles.
Closing the usages popup without saving the action will not discard your changes, but you will have to find the modified action in the action editor and save changes there.
State variables do not have a "draft state", which means that unsaved changes to state variables are unfortunately lost when the usages popup is closed.
3. Usages in coded component properties
Code changes of component properties are persisted instantly, and therefore follow the same UX mechanics like modifications directly in the properties panel.
The features described above are very useful to track usages across different entities. In addition to this, it is helpful to find variable declarations within the same action. This is easily possible by right-clicking on a variable and choosing "Go to Definition" or "Go to References":
textInput1 component
