Opened 7 years ago

Closed 4 years ago

#14329 closed enhancement (wontfix)

make parser friendlier about instantiating async widgets

Reported by: bill Owned by: bill
Priority: high Milestone: 2.0
Component: Parser Version: 1.7.0
Keywords: Cc:
Blocked By: Blocking:

Description

Enhance the parser to better handle creating asynchronously instantiating widgets such as dijit.Editor and dijit.Tree, that have an onLoadDeferred member to indicate when they've finished initializing.

Changes will be:

  1. parser.parse() return value augmented with then() function so that client code (including our test code) can do:
parser.parse().then(function(){
   // free to do anything with editor widgets
});

The return value from parse still needs to be an array of widgets though, for backwards compatibility.

  1. when parseOnLoad:true is defined, delay vanilla dojo.ready() calls until the asynchronous widgets have finished initializing
<script src="../dojo.js" data-dojo-config="parseOnLoad:true">
<script>
   ...
   dojo.ready(function(){
       // dijit.Tree has finished loading it's children
   });
</script>

Attachments (2)

parseOnLoad.js (948 bytes) - added by bill 7 years ago.
prototype parseOnLoad! plugin, to be used instead of parseOnLoad djConfig parameter
parserReturnsTwoPromises.patch (1.8 KB) - added by bill 7 years ago.
Patch against parser.js [28479] to return main promise for when all widgets instantiate, plus ret.loaded alternate promise that fires when all widgets have asynchronously finished loaded. But is just one promise better?

Download all attachments as: .zip

Change History (4)

comment:1 Changed 7 years ago by bill

Milestone: 1.82.0

Deferring this until 2.0. To delay dojo.ready() calls, I think we need a dojo/parseOnLoad! plugin, but that would in turn depend on dojo/domReady!, and we can't use dojo/domReady! within dijit until 2.0 since it doesn't work well in conjunction w/the synchronous loader.

Note that the parser return code has already been updated to be a Promise, although it's debatable whether that promise should fire as soon as all the widgets have been instantiated, or wait until the load promise (for things like Editor) has fired.

Changed 7 years ago by bill

Attachment: parseOnLoad.js added

prototype parseOnLoad! plugin, to be used instead of parseOnLoad djConfig parameter

Changed 7 years ago by bill

Patch against parser.js [28479] to return main promise for when all widgets instantiate, plus ret.loaded alternate promise that fires when all widgets have asynchronously finished loaded. But is just one promise better?

comment:2 Changed 4 years ago by bill

Resolution: wontfix
Status: newclosed

This issue no longer makes sense in 2.0, because widgets are parsed automatically without a call to parse(), and the Web Components spec doesn't have any concept of asynchronous initialization. This is true both for browsers with native Custom Element support as well as when using a polyfill like http://webcomponents.org/ or https://github.com/ibm-js/delite.

Note: See TracTickets for help on using tickets.