this._renderer.removeClass is not a function when using select in certain templates

[genuinefafa]

I'm using

• ng2-semantic-ui 0.8.2
• angular-cli 1.1.1
• angular 4.1.3

when trying to do a Search Selection as the docs,

this works

<!-- i'm including a template that i don't use -->
<ng-template let-option #clienteTemplate>
    {{ option.name }}
</ng-template>

<sui-select [(ngModel)]="selectedOption" [options]="options" labelField="name" [isSearchable]="true" #select>
	<sui-select-option *ngFor="let option of select.availableOptions" [value]="option"></sui-select-option>
</sui-select>

this DOESN'T

<!-- i'm only commenting a template that I DO NOT USE
ng-template let-option #clienteTemplate>
    {{ option.name }}
</ng-template 
-->

<sui-select [(ngModel)]="selectedOption" [options]="options" labelField="name" [isSearchable]="true" #select>
	<sui-select-option *ngFor="let option of select.availableOptions" [value]="option"></sui-select-option>
</sui-select>

there is an error, saying:

ERROR Error: Uncaught (in promise): TypeError: this._renderer.removeClass is not a function
TypeError: this._renderer.removeClass is not a function
    at SuiDropdownMenuItem.set [as isSelected] (dropdown-menu.js:58)
    at new SuiDropdownMenuItem (dropdown-menu.js:26)
    at createClass (core.es5.js:10895)
    at createDirectiveInstance (core.es5.js:10723)
    at createViewNodes (core.es5.js:12086)
    at callViewAction (core.es5.js:12530)
    at execComponentViewsAction (core.es5.js:12439)
    at createViewNodes (core.es5.js:12113)
    at createRootView (core.es5.js:11991)
    at callWithDebugContext (core.es5.js:13206)
    at SuiDropdownMenuItem.set [as isSelected] (dropdown-menu.js:58)
    at new SuiDropdownMenuItem (dropdown-menu.js:26)
    at createClass (core.es5.js:10895)
    at createDirectiveInstance (core.es5.js:10723)
    at createViewNodes (core.es5.js:12086)
    at callViewAction (core.es5.js:12530)
    at execComponentViewsAction (core.es5.js:12439)
    at createViewNodes (core.es5.js:12113)
    at createRootView (core.es5.js:11991)
    at callWithDebugContext (core.es5.js:13206)
    at resolvePromise (zone.js:770)
    at resolvePromise (zone.js:741)
    at zone.js:818
    at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:424)
    at Object.onInvokeTask (core.es5.js:4140)
    at ZoneDelegate.webpackJsonp.../../../../zone.js/dist/zone.js.ZoneDelegate.invokeTask (zone.js:423)
    at Zone.webpackJsonp.../../../../zone.js/dist/zone.js.Zone.runTask (zone.js:191)
    at drainMicroTaskQueue (zone.js:584)
    at <anonymous>

I can make a demo project (actually, I'm already doing it... ), but it seems like a patch kind of an issue.

[edcarroll]

Will take a look now 😃

[edcarroll]

I can't seem to reproduce this using the demo app - could you please make a plunkr from this template that exhibits the issue?

[genuinefafa]

It seems like a new issue... look at this (errors in console); if I delete [(ngModel)]="selectedGender" on src/app.ts it works (?)...

Maybe something change in latest angular version?

[genuinefafa]

This is a plunkr with the select (not working...) since previous issue.

[edcarroll]

Worked out why the new error is happening - add FormsModule to the NgModule imports. That fixes all the errors - though I would have thought FormsModule is automatically imported by SuiModule - investigating that.

[edcarroll]

Turns out I need to add FormsModule to the exports of all NgModules that use the forms functionality, in order for it to be automatically imported. However I think people doing that manually is the way to go here.

Are you able to reproduce your error in Plunkr with the FormsModule fix?

[genuinefafa]

This is a plunkr. There is something related with the surrounding html, not sure what.

My original layout was pretty huge, I did some trimming, if I continue, the sui-select works, but right now you can see the error I'm talking about.

[genuinefafa]

Check this plunkr, i did two comments in html template (the plunkr works when you remove any of the html elements). I can confirm that there is a issue with my html, but not sure what (maybe cause it is based on semantic-ui pure css?).

[edcarroll]

Thank you for the plunkr - have now got it to reproduce properly in the dev environment.

This is looking like an incredibly strange error, and I'm certain it is an Angular error.

Essentially, the dropdown component (which the select component uses to work) uses a 'secret' component to keep track of the options within itself. That is to say, there is a component that attaches to all .item elements on the page. This is why you're experiencing this with that initial div, and not when you're taking it out.

The issue is that for some reason, Angular is injecting an instance of the old renderer class, rather than the new one (Renderer instead of Renderer2) into that component, but only in some situations. This is of course very odd.

I've found an Angular issue that seems to be the same problem, but rather than just leaving this issue blocked will see if there is a workaround.

[genuinefafa]

Wowwww... That's pretty strange, you are right...

Did you notice that adding

<ng-template let-option #x>
    {{ option.name }}
</ng-template>

anywhere on the template make it work?

[edcarroll]

Did not notice that, and what an odd way to fix it...

Since there is a way to fix it, would you be happy adding that 'workaround markup' to your template, and then we just sit tight and wait for the Angular bug to be fixed?

[genuinefafa]

Yes, I can workaround like that, but once again, not sure why! 🙈

I would also recommend adding a note or something like that on the ng2-semantic-ui docs, since there maybe more people struggling with this odd issue.

[edcarroll]

Good call about a note - will rename this issue rather than add the note in the docs as it doesn't seem to be happening very often.

[edcarroll]

@genuinefafa This is apparently fixed in Angular 4.3.1, could you please test to confirm?

[genuinefafa]

yes, it does @edcarroll ! it even works on the plunkr... !!! closing this issue now.

[edcarroll]

Brilliant! I still need to add Angular 4.3.1 to the dependencies to ensure this doesn't happen again but can pop that in the next release.

[genuinefafa]

it is hard to think of it... i mean, you will require latest angular and many might not be able to update because of that...

are you sure that's the right move?

[edcarroll]

Currently the library requires ^4.1.0, and we need to change that to ^4.3.1 to ensure this bug doesn't reappear - since there aren't any breaking changes between these versions it will be fine :)

[edcarroll]

0.9.4 is now live which contains the updated dependency requirements.