patternjavascriptMinor
Constructing and initializing global objects
Viewed 0 times
globalobjectsinitializingconstructingand
Problem
I have a script for a web page that has to initialize a lot of complex event handlers on page load. Because of the large number of events and DOM elements that these events should fire for, I want to construct a global object containing all the initialization logic.
But as I'm quite new to JavaScript, I have no idea whether this is the most simple or correct way to do this. And I'm not sure I like these chain function calls:
Is there a better way to write this piece of code?
var Global =
{
button1Handler: function () {
return {
button1: $("#button1"),
init: function () {
this.button1.on("click", function () { alert("button1 clicked"); });
}
};
},
button2Handler: function () { /* */},
init: function () {
this.button1Handler().init();
this.button2Handler().init();
// ...
}
};
$(function () {
Global.init();
});But as I'm quite new to JavaScript, I have no idea whether this is the most simple or correct way to do this. And I'm not sure I like these chain function calls:
button1Handler().init().Is there a better way to write this piece of code?
Solution
First, I would suggest against the
Another thing is to avoid the unnecessary "configuration". Sometimes, it's best if the code is straight-forward. The structure of a configuration is sometimes a roadblock. Takes up too much syntax but doesn't immediately tell you what the code does.
For instance, if I was looking at this code for the very first time, I would be wondering how
Keep it simple.
On the other hand, if you have an app that is already starting to look complex, consider using a simple framework. There's Ractive, Vue and Riot which are small frameworks allow you to write self-contained portions of the site. This way, each "component" only houses functionality of that component, splitting up this "large number" into sections.
Global name. Too generic. Next, I would suggest against putting it in the global scope. You can put the declaration inside jQuery's ready handler.Another thing is to avoid the unnecessary "configuration". Sometimes, it's best if the code is straight-forward. The structure of a configuration is sometimes a roadblock. Takes up too much syntax but doesn't immediately tell you what the code does.
For instance, if I was looking at this code for the very first time, I would be wondering how
button1 is related to this.button1, what button1 should be, when is init is called, etc. Once I get the hang of it, sure it works. But what if there's an architectural change that invalidates this style of configuration? What if you've done this to 1000 things? You can't easily pull out and rewrite the code.Keep it simple.
$(function () {
$("#button1").on('click', handler);
$("#button2").on('click', handler);
});On the other hand, if you have an app that is already starting to look complex, consider using a simple framework. There's Ractive, Vue and Riot which are small frameworks allow you to write self-contained portions of the site. This way, each "component" only houses functionality of that component, splitting up this "large number" into sections.
Code Snippets
$(function () {
$("#button1").on('click', handler);
$("#button2").on('click', handler);
});Context
StackExchange Code Review Q#126424, answer score: 2
Revisions (0)
No revisions yet.