Variable name continuity

[leoj3n]

It doesn't matter much, but I was wondering what is the more "correct" variable name for the second parameter of these get functions: setVal or resolve? Also, it's not clear to me the purpose of this pattern; Is the purpose simply to avoid having {{#if promise.isResolved}} checks in the stache?

bitballs/public/components/tournament/details/details.js

Line 81 in 34dd301

get: function(lastSet, setVal){

bitballs/public/components/tournament/details/details.js

Line 104 in 34dd301

get: function(lastSet, setVal){

bitballs/public/components/tournament/details/details.js

Line 137 in 34dd301

get: function(lastSet, resolve){

bitballs/public/components/tournament/details/details.js

Line 217 in 34dd301

get: function(set, resolve){

bitballs/public/components/tournament/details/details.js

Line 241 in 34dd301

get: function(lastSet, resolve){

[justinbmeyer]

resolve is much more accurate. Sometimes other getters might need these values. Those getters would not be able to be able to read the value in the promise synchronously (there is a way as of 4.0).

[leoj3n]

@justinbmeyer Thanks. What is the alternative way for a getter awaiting a promise as of 4.0?

[justinbmeyer]

This same technique works in 3.0.

[leoj3n]

@justinbmeyer Your comment wasn't a response to me was it?

[justinbmeyer]

It was. What are you looking for? Async getters go back a long way.

[leoj3n]

Sorry, I think I probably have misunderstood you.

In your first comment, all this is clear:

resolve is much more accurate. Sometimes other getters might need these values. Those getters would not be able to be able to read the value in the promise synchronously

However, the meaning of this bit in parenthesis was not clear to me:

(there is a way as of 4.0).

I assumed you meant that in 4.0, there exists a new or alternative pattern for a getter awaiting another getter's promise (other than the one discussed in the OP). That's why I followed up with:

What is the alternative way for a getter awaiting a promise as of 4.0?

You let me know the pattern in the OP works in 3.0 as well, but it still is not clear to me what was meant by "there is a way as of 4.0" in regards to being able to read the value in the promise synchronously.

So, it's not clear to me what you were hinting at when you said:

(there is a way as of 4.0).

And that's what I was expecting a reply about!

So, what was meant by "there is a way as of 4.0"?

Anyways, hopefully my misunderstanding here makes sense and you can help clear it up! Thanks.

[justinbmeyer]

In 4.0 you could write:

get(){ return canReflect.getKeyValue(this.promise,”value”) }

[leoj3n]

That is pretty cool. Thanks