Transcluded clone is not compiled in 1.5.0-rc-0 in ui-select

[bogdanalexe90]

After upgrading to 1.5.0-rc-0, ui-select has stopped working. After a short look it seems that they use a transcludeFn with a cloneAttachFn. The cloned element from cloneAttachFn is not compiled.

I created a plunkr to show the problem:
http://plnkr.co/edit/TB59p33RPPS0rgA01tlj?p=preview

[lgalfaso]

It looks like ui-select is using an API that was deprecated in 1.2.1 90f8707

Unless someone comes with a small and clean patch, I think that this should not get fixed. Anyhow, will leave this open for other contributors to comment.

[bogdanalexe90]

I think this should be marked as breaking change since many can have this issue

[lgalfaso]

@bogdanalexe90 I agree that a notice is needed

@petebacondarwin WDYT?

[bogdanalexe90]

And btw i tried to refactor and remove require but no change. Transclude is called before clone element is compiled & linked.

Just play a bit with some break points.

[petebacondarwin]

@lgalfaso - Given that this was deprecated way back in 1.2.1 - do you think we could get away with removing it completely in 1.5? Especially if it seems that the transclude changes make it fail.

[petebacondarwin]

Has anyone created an issue against ui-select for this too?

[lgalfaso]

@petebacondarwin there is angular-ui/ui-select#1356

[petebacondarwin]

Actually I am not convinced that ui-select is using a deprecated API. The API that was deprecated was to use the transcludeFn parameter on the compile function. The ui-select is using it from the link function, which is still supported.

I wonder if the actual bug is that our lazy compilation is not kicking in for the cloned transcluded content at the time it arrives in the clone attach function?

[lgalfaso]

I think that I understand the issue. Things happen in this order:

Angular 1.4.x

1. The directive ui-select is compiled
2. ui-select wants to transclude the content
3. ui-select-match starts compilation, it has a templateUrl so the compilation continues later
4. ui-select-match template is resolved (as all the templates were already in the cache)
5. ui-select-match compilation continues and modifies the DOM
6. ui-select linking kicks in
7. ui-select calls transclusionFn
8. Inside ui-select transclusion handling function, there is a check that expects the modified DOM
   more steps that are not important

Angular 1.5.x

1. The directive ui-select is compiled
2. ui-select wants to transclude the content, lazy compilation kicks in
3. ui-select linking kicks in
4. ui-select calls transclusionFn
5. ui-select-match starts compilation, it has a templateUrl so the compilation continues later
6. Inside ui-select transclusion handling function, there is a check that expects the modified DOM. This triggers the error
   later and not important
7. ui-select-match template is resolved (as all the templates were already in the cache)
8. ui-select-match compilation continues and modifies the DOM
   more steps that are not important

It looks like ui-select is not waiting for ui-select-match to finish the compilation. Looks like ui-select has an inherit race condition that was mitigated due to the fact that the templates for ui-select-match are in the cache. This is, if the templates were in a slow server and ui-select would call transclusionFn before the server responded, then the same error would show up.

From all this, it looks like the issue is not the deprecated API

[lgalfaso]

I wonder if the actual bugs is that our lazy compilation is not kicking in for the cloned transcluded content at the time it arrives in the clone attach function?

This was never warranted, only that the cloned element would be compiled and linked at some point in time (that may turn out to be when the server responds with the template or any other reason).

[LeleDev]

+1... ui-select is the only library preventing me from update -.-

[Narretz]

@lgalfaso is spot on, ui-select only worked 100% if the templates are put in the cache. See this plnkr for a contrived example: http://plnkr.co/edit/sRIW4LJ2VpSBJZAnODvY?p=preview

Sure, that's best practice and probably no user removed them from the cache. But that doesn't change the fact that ui-select should wait for the ui-select-match to be available. A parent directive reaching into its children without any safeguards ... seems wrong to me. ui-select-match / ui-select-choices should instead call on ui-select once they are linked. Similarly to how ngMessages does it.

[Narretz]

Closing, since it's not an issue with angular core. ui-select also has a new contributor, so I'm confident this will be fixed soon.

[jfairley]

looks like it was fixed angular-ui/ui-select#1430 by you 💯