StarShine - 0.1.0 API Finalized, an App Architecture Tutorial, and Factory Inheritence

Here is the presentation on how to get started on using StarShine.

I'm going to demonstrate now how to actually make an app structured on top of StarShine.


This _eventify method will turn the private namespace of your module into an event emitter. This is useful for many things, but mostly it's a building block for an event emitter Factory. In order to expose the event factory, we simply return this; to expose the methods to the object. Finally, we wrap it in a StarShine factory. Here are some rules to remember.

1. If the parts you create should remain private, create a closure.
2. If the parts you create should only be exposed and the rest of your closures don't rely on it, create a compound factory
3. If the parts you create should be BOTH, create a factory and create an instance in your closure

In this case, I want the event emitter to be public AND private. Option three is our target.


Of course, if you wanted events to be private (and therefore not exposed,) simply include the original function that created the event emitter in the first place. You don't even need the _exposeThis function.


Finally, if I want the methods to simply be exposed without referenced internally, I can do factory re-use.


Moving on, we should create a couple of closures that define different portions of our application. I'm going to look for anything with a [data-user-control-1] attribute on my dom and put a link inside of it.


This is a lot of code to read, so take your time and re-read it.

On the highest level, we define a process. Inside this process, we define a factory for creating a dom fragment and inject it into the container AND the private namespace for later use inside of the _createFragment function.

Then we create an anchor tag using the terrible dom api (encapsulated and transparent to the API consumer!) and append it to the container defined already.

Then we add a click listener to the anchor in a separate process that triggers a global APP event. The this in the parent closure is a reference to the event emitter exposed by our app.

We define an API for the control that can be consumed by the app and anyone who has access to see the UserControl. I put a remove function into the definition of a "UserControl1" as an example.

Finally, I add an event listener to the app to listen for UserControlClick events and remove the anchor from the DOM.

If you define your Application in terms of functions, suddenly everything is modularized and is much easier to maintain. Embrace the "encapsulate and forget about it" principle because you are making building blocks and tools.

The following example is a good place to start for your app.


Experiment and make the code work for you.

Now, onto factory inheritence (as promised!)


If you must accept different parameters, or some kind of state needs to be shared between the factories, maybe it would be best to make the combined factories actual private children of the parent factory. Each factory should be a unit or an encapsulated building block designed to operate all by itself.

StarShine factory composition

It's become a habit of mine to discover and re-create my libraries with a twist using a slightly different technique. The flavor of this week is starshine.


It's easy to overlook a small library like this. Here are a few of it's features.

• StarShine() returns a factory. It's composed of the closures and objects that it gets passed.
• It has built in internal storage and private "shared" variables. (More on that later)
• Objects are defined by Javascript primitives:
  
  1. reusable closures
     
  2. properties
     
  3. methods
     
  4. prototypes
     
• Works like a function composer

Each function closure should encapsulate a piece of functionality like this: I cannot stress more that being able to share private variables between closures is a crazy fundamental tool that every developer should use. I have personally used something like this in my personal code: Each factory has it's own prototype, take the following example. There is no way to make a prototype chain using this method, or maybe there is and I'm lazy, but this seems to be the only way I know to get prototypical inheritance: If someone comes up with a better idea, I would love to modify my code to make it more flexible. Getting access to the prototype itself is useful with instanceof, but I highly doubt it is necessary. Chances are you probably just wanted to create a new prototype and set the _type property. Given the following example:
Accessing a simple property is probably going to be easier on your code and is simply faster.

This library is everything I love about javascript combined into one tiny little package, and I hope you like it.

Classical Inheritance is dead and what you can do about it

There is nothing new in this blog post, but all of this is worth mentioning to everyone repeatedly. If javascript was meant to have classes, it would have had them in the first place. Instead we are stuck with the following clunky syntax and keywords to do type checking.



Instead you probably just wanted this.



Look at how simple that is! It's so much faster. Even to a beginner programmer, the hint that this.name may actually be the name property of the object literal.

Need to do instanceOf? Why not do something like this instead?



Seriously! There's so much less code. In fact, why not just  forget the whole "new" paradigm? Well, maybe not forget, but use it wisely. It also begs the question, how do you make objects repeatedly? Don't you need some kind of overhead? What about applying prototypes to already created objects? Or worse. What about multiple linear inheritance?

Your goal when making applications is get the banana. Not the gorilla, not the jungle, and not everything else. See the following video.

Perhaps it might be overstated that using stampit is quite useful. It is also very close at getting the banana. At 10kb I found that stampit was the correct solution on the back end where we control  the modules. Size doesn't matter on the back end. On the front end, it might be more like a fruit salad to a mobile phone. I also have nothing but respect for Eric's library, because it really showcases the fundamental units of object creation.

Could you perhaps have wanted something smaller? (Yeah it's a pretty shameless plug.)

After all, passing callbacks should be really terse.

We should always remember the few components that comprise our objects and functions: Properties, values, closures, functions, prototypes, and contexts.

Edit:
Don't forget to check out the npm registry for my library composer.js.

Defining Plugin Architecture for Constructor Libraries

Even in a hypothetical world where objects are packaged into black boxes it would seem that convention and configuration butt heads repeatedly until developers are quite frustrated with their code. In the real world it's even more difficult to package up black boxes because the language architecture design is fundamentally flawed. (I'm looking at you Javascript global namespaces!)

So, I've personally set out to develop quick easy ways to make boxes that appear to be black boxes, but are highly configurable.

Here were some of the goals I had in mind for designing my personal plugin Architecture.

1. Had to be easy!
2. Had to be quick!
3. Plugin Convention over configuration
4. Boilerplate-able
5. Should give access to constructor options to determine where the construction of the object goes
6. Should provide a local scope for hidden variables relative to each object.

Here's a boilerplate you can use to create something like I'm describing.

If some of that code looks confusing to you, I suggest looking at the concept of functional expressions. They give you a "pseudo-blackbox" that can see the global namespace.

If you are good on closures, then we move on to the next step. Actually defining the code to make plugins work. Here's what I personally use:

This code is rather simplistic, but lets take a look a bit deeper to see the real beauty of it.

This little function right here is where ALL the magic happens. Let me show you an example of why this is "magic." Writing a plugin is very easy to do here.

Boom! Now you can call this:

As if that wasn't enough... let's go back and look at another example. A full on event emitter API.

Take some serious time to learn what just happened here. Each one of the functions created in that script are local to the object itself, because the plugin constructor code is called only once. This allows you to enclose private variables into a black box namespace. It's completely abstracted away to the developer behind the curtain.

In functional health,
-Josh