Skip to content
Mustry Solutionsiglint

BIND005: unresolved-property-reference

Property reference does not resolve in the view
Code BIND005
Name unresolved-property-reference
Category Bindings and expressions (BIND)
Default severity error
Enabled by default yes
Fix available no
ign-lint equivalent ComponentReferenceValidationRule

What it does

Section titled “What it does”

Resolves every property reference of a view the way Perspective does and reports those that point nowhere:

  • {../Sibling.props.text}, {./Child.custom.x}, {.../Uncle.props.y}, {/root/Panel/Label.props.text} and property binding paths with a component name that does not exist at that point of the tree;
  • relative references that climb above the root container (or start from a view-level property, which has no component);
  • { view.custom.x }: whitespace inside the braces makes a property reference unparseable for Perspective's PropertyRef and LegacyPropertyRef, so it is read as a tag path (checked against Ignition 8.3.3's parsers);
  • {this.custom.x}, {view.params.y}, {view.custom.z}, {parent.custom.w} where the custom property or view parameter is not defined;
  • references with nothing after the scope or the property type ({view}, {this}, {session}, {view.custom}, {this.props}, {../Label.props}): they match Perspective's reference grammar, so the expression reads them as property references, but Perspective's gateway rejects them ("Invalid property identifier ..., no scope specified" or "no property specified", checked on Ignition 8.3.3) and the binding fails;
  • with strict, {session.custom.x} where the project's session properties do not define x (only when the project and its parents are all linted; session startup scripts often create session properties at run time, so this is not checked by default).

Assigning to an undefined custom property or view parameter in a script creates it, so a property that a script of the view may write is not reported.

props, meta and position are not checked beyond the component: their keys depend on the component type and may be added at run time.

Why is this bad?

Section titled “Why is this bad?”

A reference that does not resolve makes the binding evaluate to null with a bad quality, usually after a component was renamed or moved. The Designer does not warn.

Example

Section titled “Example”
{"binding": {"type": "expr", "config": {"expression": "{../Titel.props.text}"}}}

Use instead:

{"binding": {"type": "expr", "config": {"expression": "{../Title.props.text}"}}}

Options

Section titled “Options”
  • validate-expressions (default true): check references in expressions.
  • validate-property-bindings (default true): check property binding paths.

ign-lint

Section titled “ign-lint”

Equivalent of the expression and property binding part of ComponentReferenceValidationRule (kwargs validate_expressions, validate_property_bindings), with the same messages in iglint ign-lint for the references ign-lint checks (relative and absolute component paths). The script part is SCR305. iglint also checks custom properties, view parameters and session properties, which ign-lint does not, and it parses references instead of matching text.

Option reference

Section titled “Option reference”

Set in [rules.BIND005] of iglint.toml (or [tool.iglint.rules.BIND005] in pyproject.toml).

Option Type Default Description
validate-expressions boolean true Check references in expressions.
validate-property-bindings boolean true Check property binding paths.

ign-lint kwargs in a rule_config.json: validate_expressions -> validate-expressions, validate_property_bindings -> validate-property-bindings.

Generated from the rule metadata by iglint generate-docs; iglint rule BIND005 prints the same page in the terminal. Source: docs/rules/BIND005.md.