Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#14733 closed enhancement (fixed)

Lazy-loadable dojox.mobile.Opener

Reported by: ykami Owned by: ykami
Priority: undecided Milestone: 1.8
Component: DojoX Mobile Version: 1.7.1
Keywords: Cc:
Blocked By: Blocking:

Description

The Opener widget can be used to pop up a widget such as Calendar, SpinWheel, ColorPalette, etc. Those content widgets, however, have to be loaded up front regardless of whether the user really uses them or not. Lazy-loading technique, which IconContainer already supports, should improve the start up performance by not loading the content widgets until they are opened by the user.

Attachments (1)

14733.patch (13.5 KB) - added by ykami 7 years ago.

Download all attachments as: .zip

Change History (9)

Changed 7 years ago by ykami

Attachment: 14733.patch added

comment:1 Changed 7 years ago by ykami

Owner: changed from ykami to Douglas Hays
Status: newassigned

Doug, what do you think?

comment:2 Changed 7 years ago by Douglas Hays

Owner: changed from Douglas Hays to ykami

Thoughts...

  • can this.lazy and this.requires be combined into a single attribute?
  • if show() is called then lazy is not set to false until the when function fires, but maybe that should go before when() to prevent multiple when() calls
  • I thought the dojo parser would search out and instantiate the dojoType widgets at load time even if they were children of another widget. How is this being avoided?
  • I'd like to see a programmatic example in the tests to make sure that works

comment:3 in reply to:  2 Changed 7 years ago by ykami

Thank you for the comments.

Replying to doughays:

  • can this.lazy and this.requires be combined into a single attribute?

IconItem has this API since dojo-1.5. I don't think we should change this unless there is some particular reason. Note that requires is seldom used in practice. It is used only when you want to load specific modules that are not in the widgets' deps chain.

  • if show() is called then lazy is not set to false until the when function fires, but maybe that should go before when() to prevent multiple when() calls

If we do so, obviously the second show() fails since the content is not ready yet. Multiple when() calls is harmless and safer I think.

  • I thought the dojo parser would search out and instantiate the dojoType widgets at load time even if they were children of another widget. How is this being avoided?

Quite simple. Temporarily rewriting dojoTypes.

  • I'd like to see a programmatic example in the tests to make sure that works

You could do like this:

var opener = new Opener({onHide:getDate2, onShow:setDate2, lazy:true}, "calPicker");
domConstruct.create("div", {dojoType:"dijit.CalendarLite"}, opener.domNode);

comment:4 Changed 7 years ago by Douglas Hays

When lazy=true, then requires is truthy and when lazy=false, then requires is !truthy. My point is that you could do away with lazy (you wouldn't even need to deprecate it) and no one would be regressed and the API would be simpler.

comment:5 Changed 7 years ago by ykami

Well, sorry perhaps my explanation was insufficient. Almost all the cases, users use only the lazy="true" option. lazyLoadUtils knows what modules to load by looking at dojoType. 'requires' is basically unnecessary in usual use cases. Exception is when you need to load missing _base modules. That could happen, at least in older dojo, when you do customBase build and widgets have no explicit deps list for the _base modules. This may not happen with newer dojo even in the sync loader mode any longer, but users may have old widgets or want to use it for other purposes, which I don't know.

Last edited 7 years ago by ykami (previous) (diff)

comment:6 Changed 7 years ago by Douglas Hays

OK, that makes sense. I don't have any objections, except I'd like to see the programmatic example in the test file.

comment:7 Changed 7 years ago by ykami

Resolution: fixed
Status: assignedclosed

In [27854]:

Fixes #14733 !strict Added lazy-load feature to Opener and its test cases.

comment:8 Changed 7 years ago by ykami

Milestone: tbd1.8

doughays, regarding the multiple when() calls, after doing some tests, I realized you were absolutely correct, and I was wrong. I fixed the patch as you suggested. Thank you.

Note: See TracTickets for help on using tickets.