FBConnect is a tiny and self-contained library to deal with Facebook SDK: just forget to put div#fb-root and enjoy the deferred object it returns.
Just include fbconnect.js somewhere in your HTML file and:
It’s possibile to specify some options:
Refer to Facebook documentation for an explanation of each options.
The most important, and likely the only you will use, is *locale* which enables localization for the UI of Facebook Connect.
View the repository on GitHub
Free for personal and commercial use under the MIT/GPL license used by the jQuery core libraries.
The Deferred/Promise pattern is great for two reason:
So far so good, but we need to keep in mind that this pattern it’s just an abstraction and we should be always aware of where, in the code, our procedure is executed.
Consider this example where a popover is used to pick up some options: the whole process is handled with a deferred() object:
And the code to trigger the popover is
What is not clear here is that the code of the function very_long_operation() is actually executed within the handler of the .click(), after the .hide() operation but before the click handler is completed.
Here is the point: if the function very_long_operation() turns out to be a long process, say 1 or 2 secs, it will take this interval for the popover to disappear after the click, since the DOM will be updated only at the end of the event handler.
From the user perspective, this results in a less responsive user interface.
This is particulary bad since we want to decouple the when from then:
The smartest solution could be a WebWorker: refactor each lines of very_long_operation() in order to exploit HTML5, but this will not be available on oldest browsers.
The quickest solution is and old-quick-and-dirt setTimeout:
It just detach the long process very_long_operation() from the event loop, letting the click handler to complete (and update the DOM), and everything is safe: the user interface and our decoupled code.
The same code using Stackable:
PS: The same result could be achieved by wrapping with the timeout trick the line deferred.resolve(‘my_choice’); but this is wrong from the point of view of code decoupling: the popover code knows nothing (and doesn’t have to) about the code executed with the resolve() statement, putting the timeout here would imply that our deferred object always assumes to deal with very long process.
Deferreds is all about decoupling
Talking with a collegue of mine I came up with this solution about organizing the code in NodeJS+Express using middlewares.
Consider this example in which we have a simple page that performs two queries and shows the result in a template.
Since everything is asynchronous, we chain in two queries in this way
There’s nothing wrong with this, the only problem is that as long as the page gets new functionalities, you keep nesting queries and asyncronous callback.
The resulting code could become unreadable after few cycle of releases.