XF 2.3 Javascript

[JoyFreak]

I have the following in the template but it no longer works in 2.3. What is causing this to break?

    <xf:js>                   
    $(".jf-wrapper").on("click", function(event) {
        $(".jf-wrapper").addClass("is-active");
        event.stopPropagation();
    });
    $(".jf-wrapper").on("click", function(event) {
        event.stopPropagation();
    });
    $(document).on("click", function(event) {
        $(".jf-wrapper").removeClass("is-active");
    });   
    </xf:js>

 

[Jeremy P]

The use of jQuery.

const wrapper = document.querySelector('.jf-wrapper')
XF.on(wrapper, 'click', (e) =>
{
    e.stopPropagation()
    wrapper.classList.add('is-active')
})

XF.on(document, 'click', (e) =>
{
    wrapper.classList.remove('is-active')
})

 

[JoyFreak]

The use of jQuery.

const wrapper = document.querySelectorAll('.jf-wrapper')
XF.on(wrapper, 'click', (e) =>
{
    e.stopPropagation()
    wrapper.classlist.add('is-active')
}

XF.on(document, 'click', (e) =>
{
    wrapper.classlist.remove('is-active')
}

Is the following correct when adding to a div class to call the above query?

id="jf-wrapper"

 

[Jeremy P]

I've made a minor edit to the above, but no the JS just attaches an event listener to the element with the class (ie. <div class="js-wrapper">).

 

[JoyFreak]

I've made a minor edit to the above, but no the JS just attaches an event listener to the element with the class (ie. <div class="js-wrapper">).

It doesn't seem to work. It doesn't attach an event listener to the element <div class="js-wrapper">

 

[Jeremy P]

That's what I get for not writing this in a real editor. I've fixed a few more typos and tested it this time.

 

[JoyFreak]

That's what I get for not writing this in a real editor. I've fixed a few more typos and tested it this time.

I thought I was going mad. That worked, thank you. So just to clarify, in 2.3 jQuery no longer works? Have to recode into the native JS code ?

 

[Jeremy P]

Yeah, but we do bundle jQuery Slim now as a stop-gap measure to help ease migration pains. Things like AJAX, animations, and some event handling will still need to use the core library though.

 

[Kirby]

Yeah, but we do bundle jQuery Slim now as a stop-gap measure to help ease migration pains.

This is sad news

IMHO this will not help to "ease migration" but keep jQuery on Life Support.

If there is no real need for 3rd party developers to get rid of jQuery within their JS I expect many will just keep using the bundled jQuery slim.

Is there a performance impact if jQuery slim is used instead of plain JS?

If not:
Why did XenForo remove all jQuery instead of just using the Slim build?

 

[Ozzy47]

If there is no real need for 3rd party developers to get rid of jQuery within their JS I expect many will just keep using the bundled jQuery slim.

I thought about it for a bit, but decided against it, just in case it’s removed in the future. Bad enough I already have to update 500~ addons for 2.3 I don’t want to have to do it again to remove jQuery.

 

[Jeremy P]

IMHO this will not help to "ease migration" but keep jQuery on Life Support.

Maybe, and adding an auto-fallback to inline icons might keep developers from having their icons sprited properly. The trade-offs between maintaining some level of backwards compatibility (with an API surface area of nearly the entire code base, no less) and pushing things forward are complicated.

Is there a performance impact if jQuery slim is used instead of plain JS?

Definitely, but some prominent add-on developers indicated they planned on bundling it anyway. Having a canonical source for it meets that reality and reduces the risk of different add-ons shipping multiple/different versions on a single page. The intention is to make it easier to transition over time for developers who want/need to. In case it wasn't clear from the linked post, it is not included automatically on every (any) page and likely won't be around forever.

Why did XenForo remove all jQuery instead of just using the Slim build?

As with things like the new icon system, it opens doors to new possibilities in the future.

 

[Kirby]

Maybe, and adding an auto-fallback to inline icons might keep developers from having their icons sprited properly.

Point taken. But I think there are quite some differences between BC for FA icon usage and jQuery:
There is a high probability that FA icon usage affects end users / admins - jQuery most likely only affects developers.
So while it is certainly somewhat painful and a significant effort to get rid of jQuery, developers IMHO should be able to handle this.

Furthermore, intentionally using a fallback does not necessarily mean that a developer has not "sprited icons properly":
Think of an Add-on (Add-on A) that uses an icon that is not used by XenForo elsewhere and that Add-on uses it in places with very low traffic.

Would it make sense in this case to include that icon in the spritesheet?
Probably not, in most cases it would be unnecessary overhead.
So should the developer explicitly require the icon to be rendered inline?
That seems to be more efficient then having it in the spritesheet (and thus downloaded / parsed everywhere).

But what if another Add-on (Add-on B) uses the same icon frequently and thus the icon is included in the spritesheet?
In this case it would make more sense for Add-on A to use the icon from the spritesheet than having it inlined.

So a fallback (use the icon from the spritesheet if it is included, if not use it inline) would IMHO be ideal.

Definitely, but some prominent add-on developers indicated they planned on bundling it anyway.

Yes, and that is IMHO a major problem:
If popular Add-ons continue to use jQuery and thus users continue to use those Add-ons they will (to some extend) loose the performance benefit gained by dropping jQuery from core effectively nullyfiying all the effort XenForo went through to achieve this.

Having a canonical source is certainly better than having several Add-ons include multiple (probably also incompatible) versions on their own.
But ideally I think there should not be any jQuery used anywhere.

Of coure you (XenForo) cannot force developers to do things one way or another, but you can set up rules for resources at xenforo.com

One such rule could be smth. like

jQuery is deprecated for performance reasons, Add-ons and Styles that support XenForo 2.3 or higher should not use jQuery.
If jQuery is used for such a resource this must be disclosed in the resource description.

This does not put much additional work on developers / designers and at least users / admins could make an informed decision wether or not they really want to use such a resource.

The intention is to make it easier to transition over time for developers who want/need to. In case it wasn't clear from the linked post, it is not included automatically on every (any) page and likely won't be around forever.

It was clear (to me) that jQuery Slim is not included anywhere by default.
I hope the intention to help transitioning to "a non jQuery Add-on world" will work - but I fear it won't

 

[Jeremy P]

There is a high probability that FA icon usage affects end users / admins - jQuery most likely only affects developers.

There's truth to that, though administrators who wish to upgrade to XF 2.3 (and the end users who may benefit) are also affected if add-ons they rely on wrestle with compatibility in the interim.

Furthermore, intentionally using a fallback does not necessarily mean that a developer has not "sprited icons properly":

Intentionally being the key word. I do think improvements here are feasible and I'm hoping to take a closer look at implementing them. Though I think it's equally important not to let perfect be the enemy of good. Any given icon is roughly ~500 bytes compressed (and potentially less in the sprite) so, while including a rarely used icon in the sprite or rendering a sprited icon inline may not be perfect, it's still a big improvement over XF 2.2.

But ideally I think there should not be any jQuery used anywhere.

I agree idealistically. jQuery support is deprecated in the core and I personally would appreciate if its continued use is reconsidered. At the same time, I can empathize with developers who feel it is a big undertaking and in turn I hope others can empathize that, while we aim to do our best, perfect backwards-compatibility can make it difficult to achieve our goals.

 

[briansol]

Please make it a global toggle if it must be included.

@Jeremy P

"Include jquery slim in templates?" yes/no
leave off unless your addons don't work.

or something like that. please save those of us who don't have these needs the speed hit.

 

[Jeremy P]

@briansol It already must be included manually where required.