Intents improvements (onReadyCallback, exposeFrameRemoval)

[CPatchane]

Two main points:

• Handle exposeIntentFrameRemoval data flag to terminate the service without removing the intent DOM node directly but by providing the removal function to the client
  Example of usage: Claudy has an animated (CSS) menu closing. Using this feature it will be possible to terminate the intent .then listen the animation ending before removing the intent iframe node using the resolved removeIntentFrame function (and avoiding a sudden blank view in the Claudy view)

• Add an onReadyCallback optional argument to the create method in order to allow providing a callback function to be run when the intent iframe will be loaded (iframe onload listener).
  Example of usage: Claudy will now wait the intent iframe to be totally loaded before beginning its opening animation in order to keep having a fluid UX.

Edit: Rename exposeRemoving to exposeFrameRemoval and use a data flag instead of a method

[y-lohse]

• onReadyCallback : no problem, pretty straightforward
• exposeRemoving : this one took me a while to figure out how it gets used, but it's ok now. I think removeIntentFrame is a good name, but exposeRemoving not really. Maybe something like exposeFrameRemoval or manuallyRemoveFrame or whatever? exposeRemoving is not very clear I think.

So API-design wise that's all, the code is good too. I know you plan to update the changelog, but could you please also update the intent documentation?

[CPatchane]

Thanks @y-lohse! Sure, I was hesitating about the exposeRemoving name and your proposals sound better so I will change that 👍
And of course update the docs :)

[y-lohse]

The changes are excellent! However I'm afraid I have a new question (just thought about it, sorry).
Right now, the service decides whether or not the iframe gets closed automatically, or if the client has to do it. This means clients must check for a removeIntentFrame property all the time, because they can't know if the service will do it or not. Is this correct? Have you considered doing it the other way around, ie. the client says "Please don't remove the frame when you're done"? Would that make sense?

[CPatchane]

Hum, you're right, I'll think about that to be simpler and less error prone 👍

[y-lohse]

Ok, cool. Sorry again I didn't mention it during the first review, the thought only occured to me later :/

[CPatchane]

@y-lohse That was a very very good point in fact! Better late than never^^ Now it's even better, if the intent find a boolean exposeIntentFrameRemoval in its data provided by the client, the terminate() method will return the removal function with the doc autmatically, no need to use a different method in the service 🎸🎸
See here 3f56fb8

[y-lohse]

Great! I think this API makes sense. Ready to ship as far as I am concerned!

[CPatchane]

Thanks @y-lohse 🎉

[CPatchane]

(5) [NUA-3] ETU mes applications n'ont pas besoin de permissions pour afficher Claudy