feat: refine promise usages in smart coffee machine scripts

[fatadel]

Part of #331
Signed-off-by: fatadel [email protected]

[danielpeintner]

I am more in favor of nesting code with if/else so that I can be sure that a resolve or reject is the last possible command executed.

However if you want to keep your code style I suggest adding a return statement after resolve/reject if yet another resolve/reject can follow.

see https://stackoverflow.com/questions/32536049/do-i-need-to-return-after-early-resolve-reject

[fatadel]

I am more in favor of nesting code with if/else so that I can be sure that a resolve or reject is the last possible command executed.

However if you want to keep your code style I suggest adding a return statement after resolve/reject if yet another resolve/reject can follow.

see https://stackoverflow.com/questions/32536049/do-i-need-to-return-after-early-resolve-reject

Done!

[danielpeintner]

Thank you @fatadel . You are right this is really an issue.
I will fix it in another PR to better keep track.

May I ask you to remove the test case in this pr. Sorry indeed and thanks!

[fatadel]

Sure, no worries!

[danielpeintner]

Looks good to me.

Whether you want to use async and await as mentioned by @relu91 here is up to you.

Just let me know whether you want to make these changes or you prefer keeping it as is.

[fatadel]

Looks good to me.

Whether you want to use async and await as mentioned by @relu91 here is up to you.

Just let me know whether you want to make these changes or you prefer keeping it as is.

I would prefer to keep it as it is. async/await might make the code more understandable but for now it is consistent with other promise usages in this example (and also in others I think).

[danielpeintner]

Makes sense to me since we now have both possibilities in the examples directory (the counter uses async-await on request, see #335)