Move widgets back to modules about socialapi-dev HOT 9 CLOSED

Is the bug here "polluting the global window"? There are good things about that code being in chrome and not modules. If the problem is feeling like we're polluting the window, we can wrap the classes into the social object.

from socialapi-dev.

Was really more a "todo" as I guessed the less <script> tags and the more modules the better. Close this if that's not the case, but I'm interested in what the advantages actually are? I can see wanting the instances in there...

from socialapi-dev.

FWIW, from #developers

(2:42:39 PM) markh: We're creating an addon using XUL overlays and having a debate about where scripts should be placed. All other things being equal, should we prefer javascript modules (imported using Cu.import) over multiple <script> tags in the XUL? IOW, is there a preference to reduce the number of <script> tags?
(2:43:32 PM) khuey: JSMs are probably better
(2:43:39 PM) khuey: since those are singletons
(2:45:00 PM) ***WeirdAl agrees with khuey - script tags tend to suck these days
(3:03:13 PM) mbrubeck: JSMs are also better for easy on-demand loading, making it easier to avoid impact on startup time

Not conclusive, but certainly indicative...

from socialapi-dev.

hrmph - what's up with github's formatting at the moment!?

from socialapi-dev.

yes, JSMs have a lot of benefits, and most of the time I agree with the general sentiment. Being in chrome also has a bunch of benefits. One way to weigh the difference, does the code need to operate on a single specific window or on multiple windows or you require a singleton. I dont think script tags themselves impact startup time as much as code that is executed at script load time.

from socialapi-dev.

One way to weigh the difference, does the code need to operate on a single specific window or
on multiple windows or you require a singleton.

I can't parse that sentence, but I'm sure you are aware that each widget is constructed exactly once per top-level window and that all code in those modules is only ever called via those instances. IOW, the "classes" can be singletons and the instances attached to each window.

I dont think script tags themselves impact startup time as much as code that is
executed at script load time.

In the comments I posted above, mbrubeck said "JSMs are also better for easy on-demand loading, making it easier to avoid impact on startup time" - are you saying that is incorrect? Or that it is correct but not relevant?

I'm afraid I still fail to see any advantages to them being in chrome - can you elaborate on the specific advantages to this use-case?

from socialapi-dev.

On 12-04-18 8:04 PM, Mark Hammond wrote:

One way to weigh the difference, does the code need to operate on a
single specific window or on multiple windows or you require a
singleton.

I can't parse that sentence, but I'm sure you are aware that each
widget is constructed exactly once per top-level window and that all
code in those modules is only ever called via those instances. IOW,
the "classes" can be singletons and the instances attached to each
window.

I'm trying to describe three scenarios.

The first is code that is specific to the window level, second is code
that must operate on multiple windows. In terms of the singleton, I'm
talking about a js file that its own scope, not a class instance.

I dont think script tags themselves impact startup time as much as
code that is executed at script load time.

In the comments I posted above, mbrubeck said "JSMs are also better
for easy on-demand loading, making it easier to avoid impact on
startup time" - are you saying that is incorrect? Or that it is
correct but not relevant?

It's correct but not absolutely/always relevant. It depends on what you
are doing. Most of the time I would agree that code should be in a JSM,
it doesn't mean that is always the right way to do things.

I'm afraid I still fail to see any advantages to them being in chrome

• can you elaborate on the specific advantages to this use-case?

reduction in code, IMO less is more. There is a lot of window
management related code that becomes unnecessary if a) the code is meant
to operate on a specific window and b) that code is loaded into chrome.
As well, you dont need to hold references to window level objects,
less chance of cyclic references and leaks.

from socialapi-dev.

It depends on what you are doing.

I'm only talking about this specific code - so what we are doing is fairly well understood.

reduction in code, IMO less is more. There is a lot of window management related
code that becomes unnecessary if a) the code is meant to operate on a specific
window and b) that code is loaded into chrome.

It would be great if you can clarify this - it sounds like you are saying we would need to add more code if we moved it into a module? Can you explain what that would be?

As well, you dont need to hold references to window level objects, less chance of cyclic references
and leaks.

OK great - a specific point! So your position is that it should be in chrome simply to stop the widget needing to hold a reference to the window in ".this"? At least this is something specific we can get external feedback on...

from socialapi-dev.

moved to https://bugzilla.mozilla.org/show_bug.cgi?id=755140

from socialapi-dev.