Modeled from the (Facebook Javascript SDK), now with the facebook-node-sdk you can now easily write the same code and share between your server (nodejs) and the client (Facebook Javascript SDK).
Other
529
stars
114
forks
source link
Support isomorphic web applications with a wrapper for Facebook's official client-side SDK #152
This SDK is not intended and should not be used inside the browser. Facebook provides an official client-side JavaScript library for this.
However I understand that it is sometimes desirable to be able to import FB from 'fb'; on an isomorphic web application. So that you have access in both the client and server.
My normal recommendation on this is to roll your own wrapper. Write a file that imports fb on the server and sets it up. And a browser version of that file that exports the global window.FB.
However I do admit this library has some nice features such as the Promise mode of FB.api that would be nice to have in the browser which everyone rolling their own wrapper has to implement.
For this reason I think we could at least help make rolling an isomorphic wrapper easier. We can do this by offering a fb/browser module that will simply re-export the window.FB from Facebook's official client-side SDK, but wrap it with a few of our custom features.
Namely we would make these available in the browser:
FB.api(...) => Promise
FB.options for only the appId, version, and Promise options
This way you could write:
FB.options({appId: ..., version: ...});
if ( isBrowser ) {
FB.init({
status: true,
});
} else {
FB.options({
appSecret: "fetch this from somewhere the browser bundle doesn't have access",
});
}
We would also explicitly warn you when you forget to load Facebook's official client-side SDK
Alternatively we could also offer a fb/async export. This would export a promise returning function which on the server would just return Promise.resolve(FB). But on the client would load in the official Facebook SDK before returning the fb/browser export.
Keep in mind that there are significant differences in how things work in the client and on the server:
In the client you use FB.login and have one access token; on the server you get an access token either from the client or through the manual login flow and each request you handle may be for a different user with a different token.
In the client you always use FB and don't normally pass access_token; on the server you either always pass an access_token or use FB.extend to create instances
This means the ideal workflow is to write your own getFB(context) wrapper which on the client just returns FB and on the server returns something like FB.extends({accessToken: context.accessToken}).
However if I am to implement this, someone needs to test it and make sure it works. It's not as easy to write tests to make sure an isomorphic API is useful in practice.
This SDK is not intended and should not be used inside the browser. Facebook provides an official client-side JavaScript library for this.
However I understand that it is sometimes desirable to be able to
import FB from 'fb';on an isomorphic web application. So that you have access in both the client and server.My normal recommendation on this is to roll your own wrapper. Write a file that imports
fbon the server and sets it up. And a browser version of that file that exports the globalwindow.FB.https://github.com/node-facebook/facebook-node-sdk/issues/129#issuecomment-359261107
However I do admit this library has some nice features such as the Promise mode of
FB.apithat would be nice to have in the browser which everyone rolling their own wrapper has to implement.For this reason I think we could at least help make rolling an isomorphic wrapper easier. We can do this by offering a
fb/browsermodule that will simply re-export thewindow.FBfrom Facebook's official client-side SDK, but wrap it with a few of our custom features.Namely we would make these available in the browser:
FB.api(...) => PromiseFB.optionsfor only theappId,version, andPromiseoptionsfb/asyncexport. This would export a promise returning function which on the server would just returnPromise.resolve(FB). But on the client would load in the official Facebook SDK before returning thefb/browserexport.Keep in mind that there are significant differences in how things work in the client and on the server:
FB.loginand have one access token; on the server you get an access token either from the client or through the manual login flow and each request you handle may be for a different user with a different token.FBand don't normally passaccess_token; on the server you either always pass anaccess_tokenor useFB.extendto create instancesgetFB(context)wrapper which on the client just returnsFBand on the server returns something likeFB.extends({accessToken: context.accessToken}).However if I am to implement this, someone needs to test it and make sure it works. It's not as easy to write tests to make sure an isomorphic API is useful in practice.