Deprecated use of magic jQueryUI widget

[jnickerson1]

Hello All,

I just got this message in my web inspector:

'You're relying on undocumented functionality where Canvas makes jQueryUI widgets out of rich content that has the following class names: .dialogue, .draggable, .resizable, .sortable, .accordion, .tabs.

Canvas is moving away from jQueryUI for our own widgets and this behavior will go away. Rather than relying on the internals of Canvas's JavaScript, you should use your own custom JS file to do any such customizations.'

I am really just wondering if anybody knows what is going on because our style guide has not yet been updated to reflect this change. We are using accordions in many places and if Canvas deprecates this functionality is going to break a lot of our materials. Thus I want to get out in front of this as quickly as possible. It sounds like Canvas is going to be using their own widgets. Will we still have access to those? If so when can we expect the style guide to be updated?

Any insight into this matter would be appreciated.

Thank you

---------------------------------------------------------------

UPDATE:

A solution was found. Canvas suggests that institutions stop using Jquery UI and instead include their own custom code for such things.

[RobDitto]

Thanks for asking this!  I linked to this topic from a blog post with comments which mention the same jQueryUI libraries:

• Using jQuery without Custom Javascript

[awilliams]

 @jnickerson1  Thank Youfor staying on top of this! Is this as catastrophic as it sounds? There was such interest in https://community.canvaslms.com/groups/designers/blog/2015/07/01/using-jquery-without-custom-javascr...‌ that I think at this point there is probably a lot of content out there built off this framework. Is this something we should be sounding the alarm about more broadly? Do you think we should be trying to update all the community resources with this latest information? Do you think Canvas could do anything to help address this? I'm concerned but not 100% sure yet how concerned I should be...

[laurakgibbs]

It would be GREAT if Canvas continued to support this as a feature for users even if they are not using the scripts themselves, but I guess maybe that too much overhead for them. I was really excited about using this more, but now I am hesitant since I'm not sure if I would have any support at my school for installing and maintaining the script support locally.

[jnickerson1]

I would say it is possible that for some institutions and some teachers this is going to be fairly catastrophic. I am not affiliated with canvas, so I cannot speak on their behalf. However, when I first discovered this, to say I was alarmed would be an understatement because we were using these widgets a lot in our materials.

I do personally believe it is something that Instructure should be sounding the alarm about more broadly. I am somewhat surprised that they are not giving people more warning. Indeed the current warning is quite subtle and if you're not staring at your console all the time it could easily be missed.

After discussing this on the phone with some Canvas representatives they confirmed they are deprecating. They did not offer a timeframe but did say it would be a while yet (I don't know if that means months? years?). But it was decided that the best course of action would be for us to redo our courses using our own scripts. Lucky for us, our organization hasn't been using Canvas very long so we were able to quickly go back and redo all of our materials.

The positive side of this is that, IMO, the "widgets" that I built myself actually function better and are more performant than the jQuery UI "widgets". We also have more control over how they behave and how they are styled now. So although it was a little more work upfront, we are actually much happier with the end result.

[jnickerson1]

I should mention that I do find it peculiar that Canvas is still showing these on every institution's style guide. In fact I find it peculiar that they even have these style guides associated with each institution. The reason I feel this way is that when I asked them about it during one of our phone conversations the response was that the style guide is only for Canvas developers, not for content creators. So it remains a mystery why they would even have an institution level style guide if it is not meant to be used.

Although I do find the style guide useful because we still take advantage of other things that are NOT being deprecated such as the Flexbox Grid.

[erinhmcmillan]

Hi, all,

Information about this change was posted in the 2017-02-18 Canvas Production Release Notes. 

Hope that helps!

Erin

[laurakgibbs]

Thank you, erinhallmark‌! Can we get a translation for us mere mortals? One of the reasons the tabs and accordions are so nice is that we don't have to be sysadmins or programmers to use them. I'm not sure what this means:

Canvas engineers have already coded a temporary adjustment for these functions without requiring any immediate changes, though the adjustment will log a deprecation warning to the browser’s console and include information about how to correctly adjust the JavaScript moving forward. For concerns about jQuery loading, admins should use the global $ variable that will be loaded before the script. 

I'm about to embark on a content development project for Fall (I just started it this weekend in fact), and it sounds like I probably should not use the tabs and accordions unless I can get my Canvas admin to do something, but I don't know what I would ask him to do (and I'm hesitant also... this is not the kind of support request they probably want to get...). Any additional information would be much appreciated  — thank you!

[jnickerson1]

Thanks for keeping an eye out Erin. However, the switch from RequireJS to Webpack is unrelated to this discussion.

Although a common misconception, jQuery is not the same thing as jQuery UI.

To clarify: Canvas will continue to use jQuery (considered a necessity). Canvas will not continue to use jQuery UI (not considered a necessity).

[jnickerson1]

To make light of this, please enjoy this humorous (humorous because its true) article poking fun at how confusing it is for a new developer to learn the modern world of JavaScript (not to be confused with Java - they are entirely unrelated). It is probably safe to say that nearly every developer experiences pain/despair from this early in their career.

https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f 

[laurakgibbs]

Ha ha, we need all the humor we can get! 🙂

I teach folklore, mythology, fairy tales... and so I enjoy this cartoon about fairy tale programming:

[scottdennis]

Hey All,

Even though jQueryUI and RequireJS are not the same thing, just a reminder that the shift from RequireJS to webpack goes live with this coming release.

[laurakgibbs]

I see that this is marked as "assumed as answered" but I still have questions... not sure if they should be posted as a new question. I think these would be my questions:

1. When will Canvas no longer support the deprecated jQueryUI options?

2. Is someone going to go through the Community space alerting people not to the end of Canvas support for these jQueryUI options? I've seen jQueryUI mentioned and highly recommended by multiple users in multiple places; that was what finally persuaded me to give it a try last weekend.

3. What exactly would be required for jQueryUI to be supported by local Canvas administrators? Will Canvas prepare documentation so that it will be easy for local administrators to provide that support if they agree?

4. Is there some kind of way for individual faculty to run a report that would identity deprecated jQueryUI instances in their course spaces and/or for system administrators to do so across their system?

I was excited by the results I had experimenting with jQueryUI over the weekend, but I'm definitely going to hold off on using these features in the current uncertainty. My concern is more for people who are heavily invested in this design feature whose Pages are going to become very unattractive and perhaps even unusable when support for the jQueryUI comes to an end.

[awilliams]

Great questions laurakgibbs. I'm thinking we might just turn this into a discussion instead of a question.  @jnickerson1 ‌would you have any issues with us hijacking your question to use as an ongoing discussion?

[jnickerson1]

Not at all.

[laurakgibbs]

Good idea! I am creating new discussion post and will link back here.

[laurakgibbs]

Continuation of this question as an actual discussion here:

https://community.canvaslms.com/thread/15981-whats-going-to-happen-to-deprecated-jqueryui 

Thanks, everybody!

[ryan · Accepted solution]

Hey everybody, this is Ryan Shaw, from the canvas engineering team. I see a lot of great questions here and some worry so I wanted to chime in to provide some guidance and assurance.

A little background: Canvas has, for a long time, used jqueryUI for our own widgets. So when you see a modal dialog pop up or an accordion or a group of tabs, they were probably using jQueryUI. One day, after talking with some awesome customers at instructurecon that were creating their own content, we decided to add this little piece of code: https://github.com/instructure/canvas-lms/blob/stable/public/javascripts/instructure.js#L66-L101 so that if you added class names like .tabs, or .accordion to your content it would automatically turn that element into that kind of jqueryUI widget for you without having to write any code yourself.

The problem:

First, sometimes the markup that gets created from people doing this in their content is not accessible. So, for example, users using a screenreader would not be able to use that content. That’s a huge bummer for them so we wanted to make sure we weren’t contributing to that.

Second, we are starting to rely on React.JS more and more in our front-end code, and we have even written our own UI library (http://instructure.github.io/instructure-ui/) that is built on React and is much more modern, has better UX, fixes a ton of bugs that would pop up with jqueryUI widgets and, has some of the best accessibility support of any UI lib I’ve ever seen. So we have started replacing places we were using jQueryUI widgets to use instructure-ui widgets and using the latter exclusively for new code.

So eventually, we hope to get to a point where there is nothing that canvas is doing that is using jqueryUI and loading it will make canvas slower for everyone. jQueryUI is a big javascript library, and loading all of it's code on every page has a real cost in terms of time it takes to download and view every page. We don’t want to slow down all of canvas for everyone even if they are not using this.

That's why we put that warning message in there. And in general, it will be safer and less brittle for your custom interaction code to not be dependent on canvas’ code. So us making a change doesn’t break your code and vise-versa. That’s why we recommend loading your own widget library in your custom ThemeEditor JavaScript file if you want to add custom widgets to your content.

As far as when will canvas stop using jqueryUI anywhere, I’ll be the first to tell you that it will take a long while...like measured in years, not months. And as long as we are loading jQueryUI widgets for something we need on the page, there’s no reason not to expose it like this for you to use too.

So the “official” future-proof, encouraged way of adding your own widgets is to include your own UI library in your custom JS file so it is not dependent on anything from canvas’ code. (On a side note, if you are going to do that, make sure that you are using a library that has good accessibility support, there are a lot out there that look nice but are unusable by screenreaders)

But, if you have a bunch of content relying on this and you are willing to stay on top of things, and check the release notes and react if canvas does stop using jqueryUI, you are free to do so, however it is now considered “unsupported”. But we will say something in the release notes if we ever do remove this feature, and in the worst case scenario you could just add jqueryUI to your custom ThemeEditor JavaScript file and a similar snippet to what we did for this and not have to change any of your content even after we stop supporting this.

I hope that helps clear up some of the what, why, and when behind this question. I love reading these forums, you guys are so innovative, so helpful to each other and your passion to create great educational content shows!

[sciosciap]

Hey Ryan - is there any way to incorporate the new React elements into Canvas Pages?

[sonya_corcoran1]

I have this question also Deactivated user‌ - i.e are the ReactUI components on the HTML editor whitelisted?

[James]

I am not a React expert, but I spent some time talking with Ryan in April and have a better sense than before. I left without a good solution, so I can't tell you what to do.

I'm not completely sure what you mean by ReactUI components, so I'll try a couple of different paths.

First, there is an HTML whitelist of what is accepted. Other items will be rejected. So, if you're talking about things like this React Component from the Icon section of the Style Guide, then the answer is no.

import { IconAddLine } from 'instructure-icons'

function MyComponent () {
  return <IconAddLine />
}‍‍‍‍‍

Those React components are not HTML, they're JavaScript-ish, but they're not even real JavaScript, it's JSX, which needs processed with React. You can use React without JSX, but not JSX without React (don't take that as an absolute statement, take it as a strong recommendation).

If that's what you're talking about, their recommendation in the Style Guide is for creating your JSX file to compile into JavaScript for inclusion in your project. They are definitely not mean to be included in a regular HTML page. You may be able to add them as part of the packaging with your custom JavaScript at the account or subaccount level, but more likely for someone writing an LTI who wants to make it look like Canvas, not for someone adding enhanceable_content type stuff within a page.

If you're talking about adding data-reactid or other react attributes to items, then no. You should never add those directly to a page, but let React add them for you. React has a virtual DOM and it uses those to sync with the browser's DOM. You cannot add items to the browser's DOM and have React be aware of them. In fact, there was a case a couple of weeks ago where someone was customizing Canvas through JavaScript and when Canvas re-rendered the virtual DOM, it wiped out their changes (and they weren't even messing with the data-reactid part). I imagine this will happen more and more as Canvas moves more to ReactJS. On the other hand, if you add a data-reactid to your elements and it happens to duplicate one that is already there, I'm not sure what will happen, but Ryan warned me that we could break Canvas if we mess around with things in the wrong way.

It's that part that worries me the most about doing awesome things inside Canvas using React. Canvas doesn't expose their React to us and if we include our own, there's a good chance it would conflict with theirs. Yet Canvas has this really cool UI library that's accessible and all that, but they're not going to expose it to us from within Canvas and if we include it ourselves, we could break things. That's where I get the notion this would be better from an LTI perspective where your code runs totally separate from their code. But a lot of what I do is to modify the experience within the browser and add functionality there, but some of it depends on jQuery-UI, which is why I'm looking for a non-React way to replace things.

[sonya_corcoran1]

also - once jQueryUI is deprecated, do you think it's possible to query the api for all instances of the enhanceable classes and programatically update them? Thoughts!?!

[James]

Yes, this can be done, but what are you going to change it to?

A better solution might be to leave the code as it is and add the custom JavaScript to look for enchanceable_content classes and then apply the accordion or tabs or other widget to it. That way you don't need to change the content of your pages at all.

The current system adds a class of enhanced to a page once it's been processed, so you can work on your solution while you're waiting for it get deprecated. You can go through and look for .enhanceable_content that is not inside a .enhanced element and apply the changes that you would make once the jquery-UI is deprecated.

[James]

Responding to myself -- one reason to change it is to suppress the warnings about it being deprecated. I didn't think of that until I was just now playing with how to load jQuery UI.

[themidiman]

I know this discussion has had a resolution for quite some time. I just thought it would be helpful to note there is still documentation out there that this is still possible somehow without any addition to one's custom JS file:

Pop-Up Dialog Box: Canvahacks Demo Course 

Maybe someone should adjust that module in this Demo course.

[erinhmcmillan]

Hi, Jeffrey,

That course is managed by our Canvas trainers; I've sent them a note to see if they can update that content.

Thanks!

Erin

[themidiman]

Ryan or anyone else:

I answered someone's question today that somewhat relates to this: https://community.canvaslms.com/message/71157-re-have-accordions-stopped-working 

Can the status of this technique be addressed? I'm still confused how React.JS components might be accessible to HTML code in the RCE moving forward.

Thanks!

[erinhmcmillan]

Jeffrey,

Next release will include a change to deprecate accordion widgets in JQueryUI, but Ryan has also included a way to support it for institutions who aren't quite ready to transition. Watch for more information in the next beta release notes to be published June 12.

Thanks,

Erin

[themidiman]

Thanks Erin. I'll be looking for it.