Perspective relative references to parent component properties

Ignition
21

Spaces and dashes are invalid in component keys and names. Get rid of these in your component names.
Not sure why these are allowed tbh. They will work, but you can't reference them anywhere or use them in script. I think they need to be valid Java variable names

4 Likes
22

As @nminchin said, the reference parsing falls apart when it hits a - or space. Replace them instead with underscores if you feel you need the separation.

Basically if you wouldn’t use it as a variable name in script, don’t use it as a component or property name.

2 Likes
23

Thanks guys.. oh dear.. I think a co-worker mentioned this a while back but it must have slipped my mind. Harsh lesson to learn if I need to change a whole lot of stuff now.

24

Yeah this is frustrating. I have a component with custom properties that its children refer to using expression paths, and I’d like to be able to duplicate the component and have those references just work. Instead, the fact that the duplicated component has a different name means I need to find and update all of those paths with each duplication I make. I could use script transforms instead of expressions since their paths don’t have that limitation, but then I’d be sacrificing efficiency.

25

I've started to get in the habit of putting custom props at either the view or root level that are bound to the "deeper" props that I need to reference elsewhere. Then just reference those instead of the component prop directly. Helps if you later decide to restructure things. The most you have to do is just update the bindings on those view/root level custom props.

1 Like
26

That’s what I normally do, too. I’ve even made the argument that IA made a mistake by allowing custom props on anything but the view for that very reason. However, it does make it more convenient for quick “one off” projects that you know you won’t be having to expand or maintain, like the one I was working on yesterday.

1 Like
27

Component level custom props are useful when it's truly something you are doing internal to the component... but yeah, try to expect you'll need it elsewhere, and do it at the view..

1 Like