Deprecate the remote option of modals?

[cvrebert]

• @fat closed possible implementation to address #13183 #13788 (which would have added the completely-reasonable ability to disable unwanted caching for remote)
• remote doesn't currently give any "loading..." (or similar) visual indication while the network request is in-progress, and doesn't fire any "loading started" event
• remote doesn't currently give any visual indication or fire any event when the network request fails
• Depending on the use-case, the user may want to either reuse or refresh the modal's header/footer. In older versions, the user had no nice way of reloading the header. In newer versions, users who don't want to modify the header must regenerate it on their backend anyway. (See Add option called 'remotePlacement' for modals #13597)
• The existence of remote can discourage the use of client-side templating, even when it might be a preferable option.

So, I think we have 3 options:

1. Add several features to remote modals.
2. (This PR.) Deprecate remote modals.
3. Status quo: Intentionally leave remote modals in a somewhat half-assed state.

CC: @fat @twbs/team for discussion

[hnrch02]

I'll also leave some feedback: I think this is the right way to go. As was stated previously, the remote option is indeed in a "half-assed" state. I'm thinking though, maybe we should mention jQuery#load as a starting point in the docs to help people transition away from using this option?

[cvrebert]

Yeah, that'd probably be good. I'd want to also add some link about client-side templating.

[fat]

yep, this sounds good to me. I think both ideas about giving people jumping off points if they want to go that route sound good 👍

[mbrodala]

@hnrch02 How about jQuery.fn.load instead? OTOH only people with a slight understanding of jQuery's internals will then understand that this is a prototype method.

[hnrch02]

@mbrodala I adopted jQuery#function some time ago, but I'm fine with either one. It's not that big of a deal, really.