Concern of using class restriction for social plugin directive

[NenadP]

Any particular reason why is possible to use the directive via class? I see in the source that it is either element or class.

My concern is that there is significant number of class names that the directive reserves and could easily collide unintentionally.

[pc035860]

Hi @NenadP ,

I was hoping to achieve the "seamless" integration with Facebook's social plugins. The "seamless" means that I can just get code from https://developers.facebook.com/docs/plugins/like-button, and it's ready to render.

I understand your concern, but the thing is that Facebook JS SDK actually makes an full page social plugin render call on initialization.

And HTML code like

<div class="fb-like" data-href="https://developers.facebook.com/docs/plugins/" data-layout="standard" data-action="like" data-show-faces="true" data-share="true"></div>

gets rendered into social plugins even if angular-easyfb doesn't handle it.

One way to resolve the issue is canceling the "seamless" integration, by changing the directive restrict to 'EA' and prefix the directive name with ez maybe.

<div ezfb-like data-href="https://developers.facebook.com/docs/plugins/" data-layout="standard" data-action="like" data-show-faces="true" data-share="true"></div>

The original "seamless" idea comes from that XFBML.parse requires social-plugins's class name specified to get parsed, which means you have to add class="fb-like" on it. But as the implement goes on, I figured out some hacky way to deal with it, so it's no longer a limitation anymore.