Deferred initialization of the provider

[k41n]

Hi!

Is there any way how one can init Facebook dynamically when on specific stage AppId gets known? It is being received by some query and is not defined on config phase.

So what I would like to know - is how could I provide following sequence:

1. Angular initializes
2. User clicks some button
3. We receive appId which should be used (specific customer's)
4. User gets logged in via customer's app.

Thank you in advance!

[mdedetrich]

This is actually fairly big problem on our end, because we have different config settings between staging/dev and production, and we are unable to set different AppId's because of this difference.

Maybe making the Facebook.init in the run instead of a config? Alternately we can do what is mentioned here (http://stackoverflow.com/a/17500683/1519631), however this forces the user to use $http (where as using a .run means the user can provide any service they want, you can probably accept/detect if the parameter is a promise, which would mean they can initialize facebook however they want)

Might do a pull request to implement this later tonight

[gafilson]

@matthew, do you not have the option to define your javascript differently
in different environments? Using most standard build tools you can define
different values for constants in different environments.

On Sat, Sep 13, 2014 at 11:44 PM, Matthew de Detrich <
notifications@github.com> wrote:

This is actually fairly big problem on our end, because we have different
config settings between staging/dev and production, and we are unable to
set different AppId's because of this difference.

Maybe making the 'Facebook.init' in the run instead of a config?
Alternately we can do what is mentioned here (
http://stackoverflow.com/a/17500683/1519631), however this forces the
user to use $http (where as using a .run means the user can provide any
service they want, you can probably accept/detect if the parameter is a
promise, which would mean they can initialize facebook however they want)

Might do a pull request to implement this later tonight

—
Reply to this email directly or view it on GitHub
#36 (comment)
.

[mdedetrich]

@gafilson We do have that option, however it would significantly complicate our development/production/staging cycle, seeing as our assets are statically hosted (including our javascript) in a single location

For other libraries (such as angulartics using google analytics) we are easily able to set up the id which we get when we do a request from the server. In any case its something that should definitely be possible, and I am currently coding a solution that lets you pass as a promise so you can initialize facebook ID any way you wish

Also, according to the anuglarjs irc channel, you should not be using .config for setting up stuff like id's. Its meant to be for statically defined properties, not for ID's on libraries which change depending on deployment environment

[gafilson]

@matthew, that makes sense to me. The current solution is inflexible.

W/r to your solution would the promise be accepted by the provider and then
consumed by the service during the init of the run phase? That sounds
ideal.

On Tue, Sep 23, 2014 at 11:54 PM, Matthew de Detrich <
notifications@github.com> wrote:

@gafilson https://github.com/gafilson We do have that option, however
it would significantly complicate our development/production/staging cycle,
seeing as our assets are statically hosted (including our javascript) in a
single location

For other libraries (such as angulartics using google analytics) we are
easily able to set up the id which we get when we do a request from the
server. In any case its something that should definitely be possible, and I
am currently coding a solution that lets you pass as a promise so you can
initialize facebook ID any way you wish

Also, according to the anuglarjs irc channel, you should not be using
.config for setting up stuff like id's

—
Reply to this email directly or view it on GitHub
#36 (comment)
.

[mdedetrich]

My solution would retain the current option of setting an appId via .config, but you can also specify the appId in the .run phase. The implementation of the function which accepts the appId in .run phase wraps the incoming paramter as a promise using $q.when. This means if you pass in a value, it will return a promise that immediately resolves the value, and if you pass in a promise, it will return the same promise unchanged

This means if you get your appId via $http, you can just pass in the promise encapsulating the $http request and it will work fine.

[mrzmyr]

Just wanna letting u know that a pitch PR would be really appreciated.

[mdedetrich]

Quite busy this week, so still working on it. I have had to rewrite almost all of the test cases, while learning how karma works, should be done during this week

[mrzmyr]

Just let me know if you need help about the karma tests. May you can provide the prototype first and we work out the tests together ?

[gafilson]

I'm excited about this change. Let me know also if I can help with code
reviews or anything like that.

On Mon, Sep 29, 2014 at 10:51 PM, Moritz notifications@github.com wrote:

Just let me know if you need help about the karma tests. May you can
provide the prototype first and we work out the tests together ?

—
Reply to this email directly or view it on GitHub
#36 (comment)
.

[mdedetrich]

Hey guys, unfortunately I have had less time this week then originally anticipated, so I have posted what my curent implementation is. Its unfinished but the foundations are there, will have more time to look at it next week but if someone wants to help out, then that is more then welcome!

[absolutehype]

Hey guys, i'm encountering a similar problem and am very interested in the proposed fix. Can I help at all with getting this merged in?