Perspective "Refactor" feature would be SUPER helpful

I have inherited a bunch of Perspective code from my predecessor on a project, and have spent lots of time cleaning it up. The main thing this has involved has been renaming things for clarity. This person almost never assigned a name to his components, so I see a lot of:

self.parent.parent.parent.getChild("FlexContainer_1").getChild("FlexContainer").getChild("Dropdown").props.value

Renaming and/or reorganizing these components is a challenge, since I have to make sure I track down and change every reference to them using Find/Replace. It's very time consuming and prone to error. It would save me SO much time and effort if there was a "Rename" option for components (and/or property names) that automatically found and updated all references for me.

I imagine I'm not the first person to ask for this--by any chance is this a feature that is in the works?

This advice won't help you now, but maybe it will for the future.

I find it best to bind down, instead of up. In other words, define custom properties on the root of the view and then bidirectionally bind down into the view. Then those top level custom properties become your single source of truth for use in scripting/other bindings.

1 Like

Yes, fortunately my predecessor did do that sometimes. Unfortunately, he very often would create those root properties without bothering to give THEM a name, so there are LOTS of references to "root.custom.key" :face_with_raised_eyebrow:

Unfortunately, there's not going to be a way to implement something like this. The hurdle preventing us from managing such a feature is that those names in your scripts are string values.

Now, let's imagine you want to "refactor" a component named "Dropdown" to something like "BaySelection". This would require parsing all scripts within the View for "Dropdown" and replacing it with "BaySelect". Unfortunately, this would replace every instance, including those instances which actually refer to other components named "Dropdown". I don't think we have any mechanism, which would allow us to be more targeted in this approach by only changing those instances where the relative path in use lines up with the component being refactored, because that relative path would need to be calculated from the relative path of the script location.

Doing this for bindings might be easier, but I doubt it, because their configuration in the View resource is... as strings.

Now that I think about it, what would make scripts even harder is that references might not even include the name string within the reference:

bay_select_name = "Dropdown"
# other code
self.parent.parent.parent.getChild(bay_select_name).props.value

This sort of usage would never work without incredibly advanced parsing of variables, and even then would only work if they were static.

# this would NEVER refactor.
self.parent.parent.parent.getChild(self.props.text).props.value

The Find/Replace tool will get you a bit farther than manually locating each instance, but I think that's as good as you're going to get inside the Designer.

1 Like

Yeah I figured it might be too complicated to wish for...

How about making the Find/Replace a bit more efficient? When I double click on one of its results, it tries to take me to that reference, but very often fails to get me all the way to it. If it switches me to the view in question (which it often fails to do), it will more often than not bring me to the root of the view, and I have to click my way down to it, which means scrutinizing the path in the Find/Replace window, which usually means having to resize it so I can see the whole path, and then going back and forth between the view and search results as I gradually expand the tree open to what I'm looking for.

If I could just rely on that double click always getting me right to it, that would still save lots of time and effort...