search

donejs / bitballs

A basketball tourney application.
https://donejs.com/bitballs.html
MIT License
11 stars 17 forks source link

Variable name continuity #338

Closed leoj3n closed 5 years ago

leoj3n commented 5 years ago

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?

https://github.com/donejs/bitballs/blob/34dd301f1f72078708a8def9eb3d87141575bb72/public/components/tournament/details/details.js#L81

https://github.com/donejs/bitballs/blob/34dd301f1f72078708a8def9eb3d87141575bb72/public/components/tournament/details/details.js#L104

https://github.com/donejs/bitballs/blob/34dd301f1f72078708a8def9eb3d87141575bb72/public/components/tournament/details/details.js#L137

https://github.com/donejs/bitballs/blob/34dd301f1f72078708a8def9eb3d87141575bb72/public/components/tournament/details/details.js#L217

https://github.com/donejs/bitballs/blob/34dd301f1f72078708a8def9eb3d87141575bb72/public/components/tournament/details/details.js#L241

justinbmeyer commented 5 years ago

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 commented 5 years ago

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

justinbmeyer commented 5 years ago

This same technique works in 3.0.

leoj3n commented 5 years ago

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

justinbmeyer commented 5 years ago

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

leoj3n commented 5 years ago

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 commented 5 years ago

In 4.0 you could write:

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

leoj3n commented 5 years ago

That is pretty cool. Thanks