possible implementation to address #13183

[fat]

possible implementation to address #13183

[hnrch02]

Why === here? You wanna be really sure that they explicitly want this?

[fat]

to prevent against null/undefined

[fat]

data-remote-cache="false" very different from not specifying data-remote-cache

[hnrch02]

null and undefined both are not == false.

[fat]

i know… am i missing something?

[fat]

eh '' == false which i could see happening in a data attr

[fat]

the api explicitly takes a boolean, so i think it makes sense to be explicit… but also dont really care

[hnrch02]

That's exactly what I was asking with

You wanna be really sure that they explicitly want this?

So, never mind then.

[fat]

yeah sorry, i was having trouble following

[juthilo]

To clarify just in case, I'm perfectly fine with whatever operator you choose obviously, just curious. :)

[cvrebert]

At this point, I'm in favor of deprecating remote and removing it in v4, and thus also not in favor of this feature request. That's just my 2¢ anyway; it's obviously your call.

[cvrebert]

(If merged, would implement #13087.)

[cvrebert]

@fat So, should we close #13183?

[fat]

At this point, I'm in favor of deprecating remote and removing it in v4, and thus also not in favor of this feature request

I'm fine either way. I wasn't super keen on it, but also people non stop complained about it… and i can see the use case where it's nice to be able to have a data attr load in content if you dont know what you are doing and just trying to hack up something quick/dirty.

I'm actually thinking that in 4.0 (or sooner) i want to add dispose methods to all the plugins which clean up the listeners and unbind data, etc.

Then in that case i could see an option like disposeOnHide or somethign to that effect (which would address this, without having to do the weirdness with the data attrs and would avoid nesting it under remote).

[fat]

@cvrebert

i'm going to close this pr. I'll leave it to your discretion if you want to close #13087.