Coding Pattern Help

29 views
Skip to first unread message

reedlauber

unread,
Jul 3, 2012, 12:38:06 PM7/3/12
to phil...@googlegroups.com
I've coded myself into a corner and could use a fresh perspective from my fellow JavaScripters.

I've been using the same pattern for writing application-oriented JS for a while now. I call it the Manager-Component pattern. There is a single "manager" that get executed for a given environment (page load), and it can have one or more "components", which do the actual page for feature-specific stuff.

It looks like this: https://gist.github.com/3040693

Version 1, is what I used for years, and it worked well.

Eventually, I tired of writing the same component definition code over and over, and wanted to abstract it, and came up with Version 2. It attempts to handle the common stuff (merging options, meeting the interface requirement, etc). It was somewhat of an improvement, but had some downsides that I felt created clumsy/ugly code (e.g. hidden ".pub" and ".oninit" properties that I had to remember to access.

I made another attempt a more elegant solution and came up with Version 3. This time, instead of the component factory creating an internal object, it returns a function, just as the original version did, and wraps everything up. I was pretty pleased that this further simplified things and was even more elegant. But it has a downside. The first two versions allow me to define private variables and functions inside the component, but outside the public code, and it's all scoped to have access to all the same private variables. Version 3 has limited me down to the single init callback, which means I've lost my access to constructor-time code, as opposed to initialization-time code.

Can anyone thing of another way to organize the component factory such that it's relatively simple and elegant, but maintains access to of those distinct steps?

Thanks.
 
Reply all
Reply to author
Forward
0 new messages