Skip to content

compareWith for RadioControlValueAccessor #28486

Open

Description

@sclausen

🚀 feature request

Relevant Package

This feature request is for @angular/forms

Description

I want to bind objects to radio button values and need an own function for comparing the ngModel with the value.

Describe the solution you'd like

I suggest the RadioControlValueAccessor should have compareWith like the SelectControlValueAccessor.

Describe alternatives you've considered

Activity

  1. added this to the needsTriage milestone on Feb 1, 2019
  2. kara commented on Feb 5, 2019

    @kara
    Contributor

    @sclausen can you add some more detail to this? suggested use, etc

  3. added
    featureLabel used to distinguish feature request from other issues
    on Feb 5, 2019
  4. modified the milestones: needsTriage, Backlog on Feb 5, 2019
  5. sclausen commented on Feb 7, 2019

    @sclausen
    Author

    @kara If I provide an object as my [(ngModel)] and want to have the radio button's [value] to be an object too, the radio button directive never marks the radio as checked, since it compares by strict equality.

    If this lines could be copied to the radio_control_value_accessor.ts and writeValue could be changed to the following, it would be easy to implement a custom function to check the identity.

      writeValue(value: any): void {
        this._state = this._compareWith(this.value, value);
        this._renderer.setProperty(this._elementRef.nativeElement, 'checked', this._state);
      }

    I would've provided a PR, but don't know how to write a test case for this.

  6. adam-marshall commented on Sep 23, 2019

    @adam-marshall

    I need this too. I am using [compareWith] for select controls, but there is no equivalent way of getting this to work with radio buttons.

    The justification is the same as the following issues, but for radio buttons instead of select:
    #13268 (comment)
    #13295
    #12742
    https://stackoverflow.com/questions/40325480/angular2-ngmodel-ngvalue-select-option-object-equality-across-different-instan

    Therefore it would probably be intuitive for radio_control_value_accessor.ts to use the same pattern?

  7. adam-marshall commented on Nov 21, 2019

    @adam-marshall

    There is a related issue on material which this would resolve too: angular/components#10495

  8. angular-robot commented on Jun 4, 2021

    @angular-robot
    Contributor

    Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

    Find more details about Angular's feature request process in our documentation.

  9. angular-robot commented on Jun 24, 2021

    @angular-robot
    Contributor

    Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

    We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

    You can find more details about the feature request process in our documentation.

  10. Kienz commented on Jun 25, 2024

    @Kienz

    Is this planned for future releases?

  11. arturovt commented on Sep 29, 2026

    @arturovt
    Contributor

    @JeanMeche this can be closed. freq1: low and feature: under consideration since 2019 with no duplicate reports, and adding an input to RadioControlValueAccessor is new public API in a package that is only being maintained.

    There is also an existing route: identity comparison works if the bound object is the same instance, which is the normal pattern for radio groups over a fixed option list.

    Signal forms is where value comparison and transforms get a design, so raising the use case there is more likely to go somewhere.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area: formsfeatureLabel used to distinguish feature request from other issuesfeature: under considerationFeature request for which voting has completed and the request is now under considerationfreq1: low

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      Sponsor
      SponsoredKunjungi sekarang
      Promo