Inline Discussions JavaScript not being cached

Description

The inline discussion block's JavaScript links (discussion.js, discussion_vendor.js) are being spit out as the un-minified versions, meaning that it's also not being properly cached at the nginx level. This means that the browser must always request the asset, unlike other XBlock/XModule JavaScript assets that are served with a very long cache life. The result is a slower browser load time and millions of unnecessary requests for these assets.

The JavaScript for other XBlocks (e.g. Verticals) do seem to be generated in the correct way. The reason this falls under the PERF team as a ticket is that the DiscussionXBlock seems to be using built-in functionality in the proper way (calling openedx.core.lib.xblock_builtin.get_js_dependencies), so this is an XBlock infrastructure issue, and not just a problem with an individual block.

Steps to Reproduce

None

Current Behavior

None

Expected Behavior

None

Reason for Variance

None

Release Notes

None

User Impact Summary

None

Activity

Show:
David Ormsbee
July 3, 2017, 8:37 PM

Okay, so my read on how this issue arose is:

1. When the XBlock conversion was done for the DiscussionsXBlock, its CSS and JS assets would no longer be part of the big XModule bundles.

2. Since the discussions-related assets are grouped bundles (discussions_js, discussions_vendor_js), we wanted to be able to pull in entire bundles instead of individual files, as is supported by an XBlock Fragment's add_javascript_url(). To that end, openedx/core/lib/xblock_builtin/_init_.py was made with get_css_dependencies() and get_js_dependencies()

3. However, get_css_dependencies() and get_js_dependencies() only does naive checking of the pipeline and doesn't have the more painful logic that static_content.html and pipeline_mako/_init_.py have in order to make it work with the minified bundled asset.

I don't want to make the get_xxx_dependenices() functions smart enough to spit back the minified versions. Eventually, we'll want the XBlock runtime to understand bundling, especially for the case where multiple XBlocks want to bundle the exact same library. But that should be built on newer infrastructure that makes use of Webpack, and should not be tied to the the Django-based asset pipeline that we're actively trying to deprecate.

Instead, I'm going to make it so that the get_xxx_dependencies() methods always return the full list of assets, which will then be individually added to the fragment. This isn't ideal, but it gives us a simple, consistent interface for XBlocks and static assets that does the right thing with respect to caching and the CDN.

Assignee

David Ormsbee

Reporter

David Ormsbee

Labels

None

Reach

None

Impact

None

Platform Area

None

Customer

None

Partner Manager

None

URL

None

Contributor Name

None

Groups with Read-Only Access

None

Actual Points

None

Category of Work

None

Platform Map Area (Levels 1 & 2)

None

Platform Map Area (Levels 3 & 4)

None

Story Points

2

Sprint

None

Priority

Unset
Configure