fa-surface does not work with ng-bind-html

[bennewton999]

I'm trying to convert a current angular app view to a <fa grid>, but I am passing html snippets to the <ng-repeat> using an ng-bind-html. However, ng-bind-html does not work when used in a <fa-surface>.

Here is the code:

<fa-grid-layout fa-options="myGridLayoutOptions">
    <fa-surface ng-repeat="data in wallData" ng-bind-html="data.wallData"></fa-surface>
</fa-grid-layout>

[bennewton999]

I found a work-around. I'm not familiar with Famous enough yet to know if this is an issue or this will break elsewhere or in the future..

Adding a div in the <fa-surface> repeater with the class of fa-surface and adding the ng-bind-html to that element fixes the problem.

<fa-surface ng-repeat="data in wallData">
  <div class="fa-surface" ng-bind-html="data.wallData"></div>
</fa-surface>

[zackbrown]

Hey @bennewton999 — this is exactly the solution I would recommend.

fa-surface plays the unique role of being the interface between Famo.us and normal DOM. As a result, it's sometimes not cut-and-dried from a library perspective which responsibilities it should take on. We've had to special-case several Angular features/behaviors (e.g. ng-class, ngAnimate handlers) for fa-surface. ng-bind-html would need to be similarly special-cased. Looking toward the future, I would lean away from this sort of special-casing on fa-surface. I.e. let DOM be DOM, and let fa-surface be the entry point back into DOM, but don't do all this special-casing to contort fa-surface when an application developer can very simply add and manipulate a top-level div. A div is a div and there's no ambiguity there. If anyone has a compelling case (e.g. some hypothetical performance barrier or CSS precision requirements) for supporting ng-bind-html directly on a fa-surface, we can reinvestigate this.

[bennewton999]

Excellent. Makes sense. Thanks!

[zackbrown]

And thanks for the report! Please don't hesitate to reach out if you have any other issues/questions.