Reasoning for removing promise support?

[grantholle]

I feel like callbacks are a step backwards? I have always been under the impression that promises were made to reduce "callback hell" so it seems to me removing support for promises is a wrong move. We're becoming conditioned to being able to await requests using axios, and the Inertia.visit function is just a wrapper around it...

Could someone share the reasoning for removing support for promises?

[claudiodekker]

Right, so, there's both a short answer and a long answer to this question.

The short answer

We're not removing Promises entirely. Promises are great, and we even encourage using them in some ways, we just don't want people to chain them on the end of a visit.

The long answer

There's multiple reasons:

• Chaining promises onto the end of an Inertia.visit more or less relies on the side-effect of us returning the Axios request. If we at any point decide to change the way Inertia works internally in any way (which we are, hence the deprecation warning), it would/could affect everyone's promises, which is a situation we really want to avoid if we don't have to.

• We want to make it super clear to anyone that's new to Inertia that it is not intended to be used as an API client or for anything else other than making an Inertia visit, and no longer supporting Promise chaining onto the end of a visit makes this more clear.

• Finally, we believe that if you were to use Promises, you'd be doing a lot of conditionals in your then/catch callbacks to determine what the actual state of the request is. With the Event System / Local Event Callbacks, we give you the ability to tap in to those events directly, cleaning up your requests quite significantly.

Back when we didn't have the Event System yet, the recommended way to show loading indicators was actually to use Promises to set a custom sending flag. However, as time went on, we also noticed that certain people started using Promises to do overly complicated or even strange things to implement certain solutions / reach certain goals that we felt was not the way we intended for Inertia to be used.

Now, of course it is totally okay for different developers to do things differently, but if you see a situation like this occurring more and more frequent and decide to ignore it, then over time (as a project grows in users and features) it becomes almost impossible to change it, as by that time people will have written blog posts, tweets, have plug-ins that rely on it, and otherwise recommended other people to do something in a certain way that will almost guaranteed create a situation where you'll end up upsetting a (large) portion of your users if you do eventually make the change.

I hope this answers your question.

[grantholle]

Thanks Claudio for that answer. I think the most important aspect is this:

not intended to be used as an API client

I fell into the "setting a sending/loading flag then displaying a notification" camp. I think the more it sits with me, the callbacks are an efficient solution per request. The event system is also very nice.

I've been a happy and faithful Inertia user since Sept 2019. I was on a very long project and didn't read the docs for a long time. The event system and forms helper are nice additions Thanks for all your work on it. Inertia is really a joy to work with.

[claudiodekker]

Yeah, definitely. It's a bit of a change in mindset, but we really wouldn't be making changes like these if we didn't believe it would bring a significant improvement in value/overall experience for our end-users 👍

I was on a very long project and didn't read the docs for a long time.

Just to give some info on this: This is admittedly IMO also a bit of a shortcoming on our part, as apart from the Github release notes and Twitter messages we currently don't really have a clear changelog / upgrade guide between versions on our website or anything right now, which is something we'll definitely be looking into improving in the future (#277), especially as 1.0 rolls around.

Anyway, thank you for sharing your question & feedback, as well as for sticking with us for such a long time already! 🎉 It's always great to hear success stories like these, because it means we must be doing at least something right!

[robsontenorio]

@claudiodekker as pointed on #508

• The first approach is very lightweight
• Create a method for a simple visit is really boring :(

[claudiodekker]

Feel free to ignore the warning if you're not actually using promises.. no need to make a separate method 👍

@reinink you think it's safe to remove the deprecation warning already? I doubt anyone still relies on them.

[robsontenorio]

Would be nice remove warnings :)