launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #09619
Re: js timeout issues on ec2 due to deep js namespaces
On Tue, Sep 18, 2012 at 12:51 PM, Richard Harding
<rick.harding@xxxxxxxxxxxxx> wrote:
> tl;dr
>
> Watch the naming of JS modules and their test suites. Shorter is better.
> Let's share namespaces among files/modules more.
>
>
> I've been battling to land a change that pulled a bunch of JS out of the
> product-new.pt and into a proper YUI module. Everything was fine until I
> went to ec2 land. The JS tests kept failing due to a JS timeout error.
> Thanks to Deryck's help (and sounds like Paul as well) it came out that the
> timeout was, at least partially, caused by having a large nested namespace
> for the files.
>
> The new code was in a ridiculous namespace of Y.lp.registry.product.views
> which made the test suite Y.lp.registry.product.views.test. This deep
> nesting provides a performance hit in JS and normally you'd do something
> like
>
> var ns = Y.lp.registry.product.view;
>
> In response to this, we've talked about trying to shorten this up and help
> provide a better namespacing going forward.
>
> We're proposing dropping the lp from the namespace tree all together. In
> exchange we do have to watch out for collisions among the YUI codebase, but
> it's well documented and shouldn't be an issue. For instance, we can't have
> a module that would add the namespace Y.Array. Maybe we'd have to use
> Y.LPArray if we ever really didn't have a better name for it.
>
> We also should share namespaces among files better. So we're going to push
> for a standard of:
>
> Y.$app.$namespace. For instance, my code in question added a bunch of JS
> for the product. So I created Y.registry.views.NewProduct. Other modules
> and files can share that same namespace Y.registry.views and add on other
> classes such as ViewProduct, EditProduct, etc. They can all be in their own
> files and modules, but share the same namespace cleanly and prevent us from
> layering too deep.
>
> Please keep this all in mind during code reviews and if you have any
> questions please let me know.
>
Thanks for starting this thread, Rick. Just to be clear for others,
there are two issues here:
1.) Do not use long nested namespaces in js anymore
If we do, we will certainly have performance issues. Rick's timeout
in js tests prove this. And,
2.) We should find a better naming convention that favors shorter names.
Having every object automatically start with Y.lp.$app means we're
four levels in with our object before we've written any code. I think
it's this second point that could use ideas from everyone and settle
on something for the style guide. We should strive for as shallow a
namespace as possible.
Cheers,
deryck
--
Deryck Hodge
https://launchpad.net/~deryck
http://www.devurandom.org/
Follow ups
References