Skip to content

Fix stale locale binding surviving reassignment to a literal/different value - #703

Open
Gulvan0 wants to merge 1 commit into
haxeui:masterfrom
Gulvan0:fix/stale-locale-binding-registration
Open

Fix stale locale binding surviving reassignment to a literal/different value#703
Gulvan0 wants to merge 1 commit into
haxeui:masterfrom
Gulvan0:fix/stale-locale-binding-registration

Conversation

@Gulvan0

@Gulvan0 Gulvan0 commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Demo: http://haxeui.org/builder/?a0a12ea2
Press "Set fixed", then press "Change locale"

A component property once bound to a {{key}} locale binding kept reverting to that key's value on later locale changes even after being reassigned to a literal (or a different key), since the generated isString setter only ever registered a binding, never unregistered one for a plain-value reassignment.

Add LocaleManager.unregisterProperty(component, prop) for clearing a single property's binding (unlike the existing all-or-nothing unregisterComponent), and call it from the generated setter whenever the new value isn't itself a binding. Guard it with a new isRefreshing flag set around refreshFor's own Reflect.setProperty calls, since those re-invoke the same setter with an already-resolved (non-{{}}) value - without the guard a freshly registered binding would immediately unregister itself the first time it was applied.

…t value

A component property once bound to a {{key}} locale binding kept reverting to
that key's value on later locale changes even after being reassigned to a
literal (or a different key), since the generated isString setter only ever
registered a binding, never unregistered one for a plain-value reassignment.

Add LocaleManager.unregisterProperty(component, prop) for clearing a single
property's binding (unlike the existing all-or-nothing unregisterComponent),
and call it from the generated setter whenever the new value isn't itself a
binding. Guard it with a new isRefreshing flag set around refreshFor's own
Reflect.setProperty calls, since those re-invoke the same setter with an
already-resolved (non-{{}}) value - without the guard a freshly registered
binding would immediately unregister itself the first time it was applied.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant