Ajax should utilize more complete promise

[DavidFrahm]

I find it confusing and limiting when the Ajax call returns a promise but doesn't utilize the reject capability.

So instead of handling success/failure in the resolved promise (the then()):

ATV
            .Ajax
            .post('someURL', {data: data})
            .then((xhr) => {
                // xhr succeeded
            }, (xhr) => {
                // xhr failed
            });

You would have more true promise-based logic using then() and/or catch() and/or finally():

ATV
            .Ajax
            .post('someURL', {data: data})
            .then((xhr) => {
                // xhr succeeded
            })
            .catch((xhr) => {
                // xhr failed
            })
            .finally(() => {
                // regardless of success/failure, also do this
            });

For developers who understand promises, the current implementation seems halfway done. It also prevents normal promise chaining, which flattens out the old "callback hell" problem.

[emadalam]

@DavidFrahm Can you please be more elaborate? The library implementation of ATV.Ajax is 100% promise compliant and you can do ATV.Ajax.get(/*params*/).then(/*success*/).catch(/*error*/).

As far as finally or done is concerned, it's not part of the standard ES6 or Promises/A+ specs. If you need those sugars, you can ditch atvjs provided ajax in favour of other libraries that provide finally/done out of the box. By the way even the native fetch would give you the same then/catch, without finally, as it's not part of standard promise specs :)

Provide more infos if you meant something totally different that I somehow missed here, else can we close this issue?

[DavidFrahm]

Definitely... I should have played with the code more. I just based my request off of the sample code (which never shows a catch()) so I assumed it didn't work.

And the finally() I should not have combined in my example code for what I expected or wished for.

I would recommend changing the sample code to be more fully promise based to suggest best practices, however that's just my opinion.

BTW, Thanks for everything you've done with this incredible project. It is enabling our team to experiment with some Apple TV stuff while still remaining mostly-JavaScript focused.

[emadalam]

I would recommend changing the sample code to be more fully promise based to suggest best practices, however that's just my opinion.

Sure, I totally agree that the sample code should have been more thorough, my apologies. Due to the lack of time I'm not able to invest more effort to this project, and being the sole developer, it gets difficult to show all possible use cases through examples and sample code. There's a lot baked into the library, and the documents and examples just scratch the surface. I've created milestones and issues to tackle every aspect of possible enhancements to the project, including documentation updates, will definitely take it further, but expect delays unless there are more contributors.

BTW, Thanks for everything you've done with this incredible project. It is enabling our team to experiment with some Apple TV stuff while still remaining mostly-JavaScript focused.

I'm glad it's working out for your team, that was the whole point of open sourcing this, fast prototypes without much noise. I did not want other JavaScript developers to have the same frustration that I went through writing the initial TVJS application. By the way, it's not just for the experiments and prototypes, I can assure you there are many full fledged complex streaming apps (couple of which I hand coded myself) running in production, written solely using atvjs. May be you'd find below links useful.

• Movie Catalog App
• AppleTV App Boilerplate
• Building AppleTV App - Presentation

And do spread the word about atvjs, spread the love ❤️