Radio group for radio buttons not working with HTML elements between

Bug, feature request, or proposal:

When there are HTML elements between and the group is not working / model propagation

What is the current behavior?

The model is not propagated to the radio buttons / the default button is not selected

What are the steps to reproduce?

           <md-radio-group [(ngModel)]="predefined">
                <div class="div-block">
                    <md-radio-button [value]="true">Predefined library</md-radio-button>
                </div>
                <div class="div-block">
                </div>
                <div class="div-block">
                    <md-radio-button [value]="false">Own library</md-radio-button>
                </div>
        </md-radio-group>

What is the use-case or motivation for changing an existing behavior?

See image:

Predefined should be selected, when the divs are removed it works

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

beta.10

Is there anything else we should know?

[julianobrasil]

Your code seems to be working in this plunk: https://plnkr.co/edit/otduEe4VklHBoJ8SZSfI?p=preview

Will try to isolate the problem, but i'm currently under a deadline

[rkrzewski]

I'm also experiencing this problem in my application beta.11. I've tried reproducing it a plunk that reflects the relevant fragment of my app: http://plnkr.co/edit/RYAnNxLeWODXTds9tqL0?p=preview but alas, there it works correctly.

There's something fishy going on here: https://github.com/angular/material2/blob/7fe37e580192959f989884372453d486a86ffed5/src/lib/radio/radio.ts#L127
In the plunk MdRadioGroup._radios._results contains two MdRadioButton objects, whereas in my application it is empty despite a bunch of buttons being present in the DOM. I thought that maybe @ContentChildren needs {descendants: true} argument, since the default appears to be false:
https://github.com/angular/angular/blob/e2e8ba6ffa382319c4f8b8cc4bc43814e7c0f97c/packages/core/src/metadata/di.ts#L204-L209 but my plunk linked above contradicts this theory.

Any suggestions how can I help tracking this problem down would be appreciated!

Edit: fixed plunk URL

[julianobrasil]

Anything else in your bugged code? FlexLayout, *ngIf's, <ng-container>...

[rkrzewski]

I do use FlexLayout in the application but not in the affected component. All the tags and directives in the plunk are exactly as in my code modulo some CSS classes (all from Material 2) and a change listener.

The data for generating the buttons is provided asynchronously, which I emulated with setTimeout in the plunk.

[rkrzewski]

I was able to reproduce the issue in a plunk, using Material 2 alone:
http://plnkr.co/edit/aomAZuhNROAPceZT0sWz?p=preview (works with angular/material-builds@b811356)

There two radio groups displayed. The first one has <div> elements intervening between <mat-radio-gorup> and it's <mat-radio-button> and it works correctly. The second one, wraps <mat-radio-button> in a <mat-list-item> and there, setting initial state of radio button fails, because @ContentChildren(...) _radios mentioned above is empty. Debugging how the queries work is a bit over my level of expertise at this point :(

In my actual application I'm using the intervening <div> elements because I've run into that issue before and it was the workaround that I found. It used to work with beta.2. Now with beta.12 my workaround does not work any longer with the same symptoms as demonstrated in the plunk.

[rkrzewski]

I've made an experiment and edited node_modules/@angular/material/esm5/radio.es5.js changing the _radios property decorator to:

        '_radios': [{ type: ContentChildren, args: [forwardRef(function () { return MatRadioButton; }), { descendants: true }] },],

(did it this way, because I couldn't figure out how to compile my application against a locally modified material2 sources) Lo, and behold: the problem in my application was resolved. I'm going to prepare a PR with this change shortly.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}