Domino.js 2.0

[Yomguithereal]

Domino.js

This issue's goal is to hereby list some reflexions about the present state of domino.js in order to start a broader reflexion concerning a potential new future version of the library. I will add elements to this list as time goes by.

Hacks

The hack term really confuses some people that find hard to understand what they really are for. They often come to realize that they are in fact hooks and do not get why they are not called thusly. It might be interesting to change "hacks" to "hooks" then, while keeping the hack term for the die hard users.

Events unregistered in controller

Some people often find themselves wanting to dispatch an event which was not explicitely registered within the controller. The main workaround is then to add a useless hack containing only a triggers attribute with the name of the event one wants to dispatch. While I understand and respect the reason why this is done so, it pisses some people that want to do as they please. Maybe this could be part of the strict option for the controller's constructor. A user using the strict domino mode would have to go by the former legit rules while another one without the strict mode could do what he wants.

Namespaces

I often find myself namespacing my events. For instance, every events concerning a precise thematic would be called 'theme1.foo', 'theme2.bar' and so on. Maybe something clever might come along the adjunction of formal namespaces within domino's logic.

Events & Patterns

The possibility of event reception by pattern might be useful. Especially when some generic event should be received by only one specific module while not trigger a function in every similar module. Along with namespace, it could provide more efficient event targeting.

this.triggers.events['module1.*'] = function(d, e) {
  // e.matches could receive the matched part of the pattern for instance
};

Heavy controllers

Starting from medium-sized projects, domino controller might become really heavy and bloated.

What I usually do in this case is to separate the controller into several files: one for the properties, one for the services, one for generic hacks and then one for the controller that get all of the precedent to load itself.

Then, because a lot of my hacks are often specific to some modules, I often write my hacks into the relevant module file. I therefore concatenate all the hacks array I produced in the module files into the controller.

Part of those practices might be integrated into domino's logic in a way.

API Simplification

this.triggers.events['eventName'] feels quite heavy. Something like this.receive or else might be clearer.

Dispatching events from modules constructor

It is impossible to launch an event from a module constructor in the current version. Do we want this to be possible?

API Consistency

The this.get('key') and this.key = 'value' syntax is not consistent.

Services

The contentType / dataType distinction is confuse.

Updated events

Considering a property "user", when updated and an event named "userUpdated" is fired, it would be nice to have the new value in the e.data of the receptor as well as the existing d.

Custom domino methods

Add the possibility to add some custom methods to the modules for instance. I often find myself in need for a dispatchRealtimeEvent which encapsulate some repetitive logic.

Events functions scope

The this in the this.triggers.event[x] functions is somewhat inconsitent. Calling them within the scope of the module would be nice.

Guarded events?

Find a sensible way to integrate filters to receptors and hacks.

[jacomyal]

Hacks

Definitely.

Events unregistered in controller

We need a better solution for that if we want to allow people to use events that are not declared in the controller. Maybe the solution would be to improve logs and stats, such that it is still easy to debug even if the events are not registered in the controller.

Here are some ideas about it:

• Having a method in the controller logging some info about a specific events, like how many / which hacks / properties / services / modules registered it / dispatched it.
• A specific status for these events, that can appear in the logs.

Logs

Logs need to be entirely redefined. I'd like to have them more shiny (colors and stuff), more insightfull, and more easily customizable / filterable. I recently saw someone presenting Woodman, that seems to have a lot of great features such as choosing the target of the logs, easily filter the sources, etc...

[Yomguithereal]

I am afraid this part is now longer relevant since we evolved quite a bit since.