JavaScript goals in 3.0
For 1.9 we wanted to move completely to AMD, but for BC we kept loading elgg.js synchronously (elgg_load_js) so any following scripts would have immediate access to elgg.* functions. For FC, it was packaged as an AMD module so future modules/scripts could require() it.
This is not a bad situation. Although much core code isn't in modules, conversion is an easy process and Ismayil and others have started this; easily finishable by 3.0. But I think there are a few more goals we should address:
- Cleanly packaged elgg module that can be loaded async or not at all.
- Async loading of jquery and jquery-ui modules so sites can opt out as they wish.
- Allow concatenating modules likely needed on first load.
- Use async translation with tiny initial language module (#9028).
- (?) Allow advanced site builders to use webpack (and CommonJS modules) without ripping out everything.
- Allow sync scripts before the RequireJS environment is set up (necessary if the module version depends on modules not available. We do this with jQuery & UI).
- Allow sync scripts after RequireJS is set up. (e.g. we allows 3)
- Formalize passing page-specific data to modules.
- Standardize initializing/loading modules with ajax-loaded HTML. (calling require() in inline script works, any better ways?)
- Reduce/isolate dependencies on jQuery IU.
I've started cleaning up the boot process in #9385, particularly visible in the page/elements/foot view. There elgg.js is AMD-loaded and, for BC, any views extending it are pushed off to another script loaded after elgg is defined. I think (2) will be easy. (3) is easy as long as they are clean AMD modules.
How would you order these goals in importance to the platform?
- Steve Clay@steve_clay
Steve Clay - 0 likes
- ihayredinov@ihayredinov
ihayredinov - 0 likes
- ura soul@tunist
ura soul - 0 likes
You must log in to post replies.I think ideally each page would output the page-specific config data, and load 1 script like "elgg/main-$lang.js" containing all of Require, jQuery, UI, elgg.js, languages/$lang.js, elgg/init.js, elgg/ready.js, elgg/Plugin.js, and any other modules that plugins want on each page.
I'd very much like to see #9028 get some consideration. The synchronous elgg.echo forces us to block scripts on a 28K (probably much more for a real site) language file. Async elgg/echo would pave the way towards bundling a very small partial translation set with other expected modules.
8. Server side hook for elgg.config could be useful.
9. With your new elgg/Ajax module, we can extend ajax output with an array of AMD modules required with elgg_require_js(). I imagine it could work with elgg_load_css() - either by parsing loaded URLs and adding missing css, or by appending them inline (with a name attribute on the tag
10. Not sure we can reduce the dependency, but we can definitely only load required ui libraries, e.g. sortable.
anything that will minimise the loading of language strings is welcome! i'm not clear though on how these changes would improve loading of strings that are initialised via PHP and not via JS.