Quote:
Originally Posted by suzzer99
I am fairly new to JS Promises, typescript and whatever else is going on here. Can anyone explain what this function is doing?
Code:
public setAccessToken(authNWait: Promise<string>): Promise<boolean> {
const ret: Promise<boolean> = new Promise<boolean>((resolve, reject) => {
authNWait.then((accessToken: string) => {
this.logger.log(`access token is '${accessToken}'`);
this.authNResolver(accessToken);
resolve(true);
}, (error) => {
resolve(false);
});
});
return ret;
}
private authNResolver: (accessToken: string) => void;
private authNWait: Promise<string> = new Promise<string>((resolve, reject) => {
this.authNResolver = resolve;
});
Is it just me or does this take a lot of the fun out of JS? These guys have factories all over the place. I can tell they come from a Java background - probably converting the app straight from Java. Everything is a damn factory.
the top level "setAccessToken" takes an "authorizor" object (think: something that makes a network call to some API endpoint that authorizes credentials, and returns, say, and OAuth token. that's what the real implementation would be. here the implementations seem to be placeholders but you should think about it in a real context.
so what *is* this authorizer object? well, it's just something that returns a promise of a string (ie, a promise of some token, which happens to be a string).
let's take a sidebar where i bash on the naming here, because that's my favorite subject. "authNWait" is a poor name, because it's a description of one possible implementation of this object. you're imagining a network call being made, and "waiting" for the response to come back. but you shouldn't be imagining that, because the whole point of the promise is to abstract that away. and who knows, maybe you're reading from the local file system in some other implementation, and you're not waiting. but mainly the problem is that the name is suggesting implementation details.
but gaming_mouse, you say, isn't "authorizor" as you described it above a bad name too? yes, it is. so what should it be named? "accessToken" would be a good name. remember: the whole point of a promise is that you can think of it as the thing being promised. It's a promise of an accessToken. Mentally, just swap that out for accessToken (and then in the back of your mind put a pin to remind you that it's possible you sometimes get an error instead of an accessToken).
So this "setAccessToken" method takes an accessToken and returns a promise of a boolean, which simply indicates if the accessToken promise succeeded or not. So this is just an old school design where the method does something, and returns a success/fail flag.
But since it's telling you if a "promise" succeeded or failed, the flag itself has to be a promise of a boolean. Once you enter promise land, everything thereafter remains a promise.
I can't really talk about the details of this fake implementation, because from what I see here I don't see the purpose of the "authNResolver" abstraction. But, eg, if you called "setAccessToken(Promise.resolve('my-token'))" it would log "access token is my-token" and then return return Promise.resolve(true) -- ie, a promise of true.
re: typescript, i've only used it some but having types is really nice. the syntax isn't fun with parameterized types, but the result of it is. if you use purescript you can get the type system (an even more powerful one, in fat) without the ugly syntax, because the type inference is so good. but that's a whole other language that compiles to js.