geomatico / geobricks-js Goto Github PK

If we use extensively geobricks-js we will have several projects coupled with the components on it. These components are going to evolve over time. Mainly at the beginning when design patterns are not mature, but also during time as technologies evolve. And this evolutions are going to make the projects that use geobricks-js out of date. Either we upgrade them, either we stick to the geobricks-js version we worked with.

Therefore I think that a branching strategy is necessary. A branching strategy that, for example, allows to use a 2 year old geobricks-js version on a huge project where upgrading to the last one is not possible. A strategy that allows too to include improvements on that version as critical bugs appear.

I have put in practice a little the one described here [1] and it did the trick. Any other experiences?

[1] http://nvie.com/posts/a-successful-git-branching-model/

I think we have to document these things:

• What's expected to be in module.config().
• Events that the module listens/sends.
• The object returned by the module.
• Used/implemented patterns.
• Any other module-specific thing.

We have to determine if we want to generate html (or other format) from the module documentation. I don't think that's necessary, so I suggest this solution:

• A comment at the beginning of the file explaining events(listen/send) and module.config()
• Inline comments in the object returned by the module.

• Add custom context parameter for listener (the this problem in instance callbacks, see #2).
• Get rid of "event" parameter in callback function (not used, pollutes code).
• Rename methods to use the common pubsub pattern naming convention (better understandability).
• Add an "unsubscribe" method (for completion).
• Get rid of jQuery dependency (loose weight, gain control).

I don't know if I can define properly the problem since I haven't run into it myself, but I think the scenario is an application that has to add dynamically several instances of the same module. How are events managed by a single instance and not by all? How are these instances built? Are the instances modules themselves?

I think Oscar proposal is to create a factory module that returns objects. Problems with the context of "this" appear and changes to the message-bus are necessary.

I may have time in the following weeks to give it a try and see how we can keep oop away from geobricks-js. I have no alternative yet, though.

bootstrap, jquery ui, nothing.

¿Maybe also OL, leaftlet? As long as we only have components based on OpenLayers there is no need to differentiate with folders.

This will make easier the search of the module that matches your application, and also may help you to select the technology in the future based on the available modules for each one.

Incorporate javascript developing tools.

As @fergonco says, each item will require a its own issue and discussion when addressed.

The following list is only an outline:

• Testing: mocha+chai or jasmine are both good candidates
• Coverage reports: istanbul? see what was used in Tunduras
• Documentation: see #3
• Code sanity: JsHint
• Compression/packing: Uglify2, cssmin
• HTML templating: handlebars
• Task automation: grunt*

(*)grunt has plugins to manage all the suggested tools: contrib-requirejs, mocha, contrib-jasmine, istanbul, jsdoc, contrib-jshint, contrib-uglify, contrib-cssmin, contrib-handlebars.