Remove jQuery by default

[simonihmig]

Rendered

[NullVoxPopuli]

This is probably blocking the jQuery removal endeavor warp-drive-data/warp-drive#5386

[tavosansal]

So how would one select an element inside a component? Using this.$ was convinient because it scoped the html of that component. Will there be a way to do that without jQuery?

[makepanic]

So how would one select an element inside a component? Using this.$ was convinient because it scoped the html of that component. Will there be a way to do that without jQuery?

Components have a element property. You can refactor this.$() to something like this.element.querySelector() (afaik this only works for components with a tagName)

[rwjblue]

afaik this only works for components with a tagName

Confirm, however in tagless components you also don’t have a this.$() so this isn’t a new constraint / change.

[tavosansal]

Makes sense...I did not know about the element property. Might be good to note to change the docs about this then and start teaching about it instead of the this.$ as present here: https://guides.emberjs.com/release/components/the-component-lifecycle/#toc_integrating-with-third-party-libraries-with-didinsertelement

[simonihmig]

Might be good to note to change the docs about this

@tavosansal Indeed, tbh I wasn't expecting to still see references to jQuery APIs in the docs. Even as part of the previous optional jQuery RFC it makes sense to only teach native APIs, especially for addons! Created this tracking issue: ember-learn/guides-source#194

[simonihmig]

This is probably blocking the jQuery removal endeavor warp-drive-data/warp-drive#5386

Just for the record: the ember-fetch adapter mixin already supports using fetch with ember-data, so you can have an ember-data app without jQuery even today. Though I agree it would be nice to have support built-in. But I would expect this to land in ember-data at least by the time, probably way before this RFC gets implemented (should it be accepted), so hopefully no real blocker!?

[jherdman]

It should be noted that ember-cli-mirage doesn't yet support fetch as it's stuck on Pretender ~1.6. This might be considered a blocker given how popular it is as a development tool.

[NullVoxPopuli]

I'd say that'd force a major version of mirage than anything else

[initram]

We should also consider the use of ember-ajax as it depends on jquery. ember-ajax is currently part of the default blueprint, and apps/addons may use that instead of using jquery $ directly. I think this should be reflected in the RFC, so that we don't end up having addons that use jquery in the blueprint after we remove jquery by default.

[jenweber]

The "How We Teach This" could mention the work that you've already done to extract JQuery examples from the docs, the jquery migration guide, and the Linting rules that are now in place.

[simonihmig]

It should be noted that ember-cli-mirage doesn't yet support fetch as it's stuck on Pretender ~1.6.

This isn't the case anymore, it is using pretender 2.1.0, so it should support (native) fetch now. So one less thing to worry about!

[simonihmig]

I just updated the RFC to incorporate the feedback...

• added a section to update the ember new blueprint, mentioning to replace ember-ajax with ember-fetch and enable the no-jquery ESLint rule by default
• mention the remaining ember-data "blocker" to support ember-fetch out of the box
• updates to "How We Teach This"

Any word from the Core team on this? If going forward with this, I think it would be good to get the deprecation messages out asap, so users/addon authors have enough time to migrate, before dropping support in the next major version. Especially as IMHO this could be regarded as part of or at least somewhat related to Octane...

[rwjblue]

We reviewed this in detail at the most recent face to face meeting (sorry for the long delay getting this feedback posted). In general, we are very much in favor of moving forward!

There are a few areas where we think the RFC needs to be fleshed out a bit:

• We need to include a plan to ensure new applications work out of the box without jQuery, this means that we need to address any of the default packages that an application ships with that requires jQuery. Specifically:
  • ember-data requires jQuery.ajax by default
  • ember-ajax would need to be removed from the default blueprint
• Ember.$ should always be deprecated (even when using @ember/jquery)
• moduleForComponent should not be modified (these "legacy" test modes are "frozen", and will be deprecated completely in a separate RFC, there is no point causing undue churn to satisify this.$ deprecation in them (you should just migrate to the new syntax))
• We need to review the ember-inspector to ensure that it is fully functional without jQuery (I believe that it works well and all features are present, but I'd like for the RFC to confirm)
• The RFC should be updated to include the deprecation guide data (or at least cross link to a deprecation guide app PR)
• Some specific mention of uses of jQuery.ajax with prefilter should be included in the RFC. (I suspect this will be a somewhat tricky one to solve, and may result in a new service in ember-fetch...)

Since we are considering this RFC as part of the Octane Edition, we are very interested in moving forward quickly...

[cibernox]

@rwjblue I confirm that the ember-inspector works in apps and addons without jquery.

[simonihmig]

@rwjblue updated again according to your feedback. Should be good for another review!

We need to include a plan to ensure new applications work out of the box without jQuery, this means that we need to address any of the default packages that an application ships with that requires jQuery. Specifically:

• ember-data requires jQuery.ajax by default
• ember-ajax would need to be removed from the default blueprint

Had this already covered in an update a few days ago, just did some further refinement.

Ember.$ should always be deprecated (even when using @ember/jquery)

Makes sense. Updated the RFC accordingly.

moduleForComponent should not be modified (these "legacy" test modes are "frozen", and will be deprecated completely in a separate RFC, there is no point causing undue churn to satisify this.$ deprecation in them (you should just migrate to the new syntax))

Same, has been updated.

We need to review the ember-inspector to ensure that it is fully functional without jQuery (I believe that it works well and all features are present, but I'd like for the RFC to confirm)

@cibernox confirmed this, which matches my experience as well. I am not aware of any shortcomings so far.

The RFC should be updated to include the deprecation guide data (or at least cross link to a deprecation guide app PR)

As we have discussed, I added a bit of direction regarding the message and tone of the deprecation guide, and believe we can flesh this out during the implementation phase.

Some specific mention of uses of jQuery.ajax with prefilter should be included in the RFC. (I suspect this will be a somewhat tricky one to solve, and may result in a new service in ember-fetch...)

Has been added (without going into details API-wise).

[rwjblue]

Thank you @simonihmig, I've added this to the agenda for this Fridays core team meeting...

[rwjblue]

Discussed with the rest of the core team at today's meeting, and we are happy to move this into final comment period.

[rwjblue]

Given that this has been in FCP for a week, we reviewed it again at the core team meeting today and are still in favor of moving forward.

Thanks to everyone for helping us hone the message, and thanks to @simonihmig for pushing it forward!