Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BACKPORT LTS] do not throw on stable elementId #18809

Merged
merged 1 commit into from
Mar 11, 2020
Merged

[BACKPORT LTS] do not throw on stable elementId #18809

merged 1 commit into from
Mar 11, 2020

Commits on Mar 11, 2020

  1. [BUGFIX LTS] do not throw on stable elementId

    When refactoring from observers to setters during the 3.11 release
    (in 405d423), an apparently-transparent change caused a regression
    around invocations of components including `elementId=...`. *Any*
    rerender of the component which included `elementId` assignment now
    triggered the assertion, rather than *only* changes which actually
    updated the value of `elementId`, because all invocations strigger
    a `set` on the property.
    
    The simplest reproduction of this bug (given a component `foo-bar`):
    
        {{foo-bar
          elementId='stable'
          changingValue=this.fromBackingClass
        }}
    
    Changing the value `fromBackingClass` on the backing class *always*
    triggers the assertion, even though it is actually impossible for
    it to change the `elementId` value, because the assertion in the
    setter throws regardless of what the value is. (The observer-based
    did not throw in the same conditions because it would not retrigger
    when the observed key on the view did not change.)
    
    The fix is to check equality between the passed `elementId` value
    and the previously set value, and only throw if they differ.
    
    Fixes #18147
    chriskrycho committed Mar 11, 2020
    Configuration menu
    Copy the full SHA
    bdc6668 View commit details
    Browse the repository at this point in the history