On 1/27/11, Brian Wigginton <[email protected]> wrote:
[...]
>
> Scalable JavaScript Application Architecture - Nicholas Zakas
> Some really great concepts in this deck, by our very own Nicholas
> Zakas. He
> confirms my thought that everything on the page should be divided into
> modules or components. Each component only has knowledge of the component
> sandbox, they don't know about any other components. Components communicate
> using the component sandbox. I'm thinking the sandbox works as a pubsub
> manager, where components can subscribe to events via the sandbox. Different
> components fire different events... One thing I wasn't completely sold on
> was one part of the slide that said the components are completely decoupled
> from the base library (jQuery, Dojo, YUI).
Instead of $ in the source, just make it a parameter for that page.
Makes sense, don't you think?
I have seen a case where developers thought that he would make the
code modularizable by making myLib.query be modular and be swappable,
so that myLib.query could be calling jQUery or prototype, and that it
would be changed in one place. But that doesn't really solve the
dependency issue because when the underlying engine is swapped out,
then there is a change propagation to every dependency to deal with.
I presume he never tried swapping the base implementation because if
he had he would have realized changing a stable foundation is risky,
even when that foundation is buggy in some way. That app was had other
more significant problems, such as generating the whole pages using
innerHTML.
I like being able to use
> $('selector') to mess with the dom, and I think you should be able to do
> this within your components.
>
Well that depends what `$` means. (and `$` is meaningless, really). If
the identifier is tied to a concretion, then you're gonna be in the
same boat of jQuery dependents, including jQuery plugins. That is: whe
jQuery is updated they have to worry about breakage. jQuery takes
major changes as NBD.
OTOH, with Dojo -- they just are too scared to change core because
they should not be violating stable abstractions principle. and so you
have `typeof it == "array"` remaining ther for years and such. OTOH,
if `$` is tied to a contract, then the code is flexible.
But an idea for a page might be:
function initPage(config) {
var selectorEngine = config.querySelector;
}
Beacuse now when you find your querySElector doesn't work right it can
be swapped out for that page not the others, so no worries about
breaking anything else.
That is an example that is about the idea for the `D` in SOLID -- DIP.
Wikipedia page for SOLID:
<http://en.wikipedia.org/wiki/Solid_%28object-oriented_design%29>
Two days ago, that page was history. But I argued about that and good
to see it is back!
<http://en.wikipedia.org/wiki/Talk:Solid_%28object-oriented_design%29>
I am satisfied with that resolution. SOLID is solid.
Garrett
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
