Setting component ID to [whatever]_0 fails silently

Dave shared this idea 4 years ago
Completed

Small, small enhancement request:


Given a component named "image_1", changing its name to "image_0" fails silently — the name reverts to "image_1" instead of either accepting "image_0" as a valid ID or informing the user that (or even why) it isn't.


I'd prefer being allowed to use "_0", but a popup that says "IDs cannot end in '_0'" would be OK, and "IDs cannot end in '_0' because XYZ" would be even better.

Comments (2)

photo
1

Dev team notified

photo
1

Thanks. Knowing that the team is notified is nice.


Any idea of whether this has been marked as "closed - wontfix" or if it's still in consideration? I know that it's a pretty low-priority request (even for me), but it would be a mildly better UX to have the freedom to rename things according to my needs, and not to the tool's, or Java's, or whatever.


Through my experimentation, it appears that an underscore followed by a number at the end of an ID is not treated as part of the user-editable label, but as an index that Justinmind manages on behalf of the user. Thus, "Element_1" would appear to be equivalent to "Element_001", which certainly was a surprise to me.


In fact, an ID like "Element_001" appears to be impossible to create.


Moreover, I discovered that it is impossible to rename "Element_1" to something like "Element_001" — Justinmind claims that there's already a component with that name. That makes a certain kind of logic if "001" maps to "1", then I'm essentially trying to rename an element to itself.


What makes less sense is that it fails with the same "The component already exists on the screen" error if I attempt to rename "Element_1" as "Element_002" — even though there is no "Element_2" anywhere in the prototype. In this case, the error message is just misleading.


All of this makes me I realize that this isn't as easy a thing to change as one might hope.


Still, a boy can hope :-).