CODEWITHSUNDEEP
javascriptmodel-view-controlleroopdesign-patterns
tau
tau

Reputation: 6749

Should the view fire events?

I have a class for part of a GUI. It is a toggle switch that has a switch public member function that puts the GUI switch into whatever position you want. When you click on the GUI element, I would like an onToggle event fired along with the GUI calling the switch function.

Here are my choices (that I'm considering and want your advice on) to implement this:

1) Make a setOnclick public member function that my controller can use to assign the firing of the event to the element and take care of the switch function call.

toggleInstance.setOnclick(function() {
    onToggle.fire();
    toggleInstance.switch();
})

2) I can just put the event firing and switch function call inside the class itself

element.onclick = function() {
    onToggle.fire();
    public.switch();
}

I think it would be nice to have the GUI classes (such as my toggle switch) entirely devoid of any logic or functionality, but I'm not sure if this is necessary.

I'm not using an MVC framework, but I do like to apply the principles of separating functionality between MV and C.

Can you think of any potential downsides to either method in the future?

Upvotes: 1

Views: 90

Answers (1)

jamesmortensen
jamesmortensen

Reputation: 34038

HTML/CSS/JavaScript:

In client side code, you have HTML that represents your content, CSS that defines your presentation of that content, and JavaScript, which you use to determine and assign the behavior of the content and presentational elements.

In short, you have the right idea here. Just by keeping JavaScript out of your HTML and HTML out of your JavaScript, you've done a lot in terms of proper planning of your architecture.

In the JavaScript, you can follow MVC, but for the most part, as long as you remember HTML is content, JavaScript is behavior, and CSS is presentation, you've done so much to make your code highly maintainable.

With that said, let's focus on your JavaScript.

MVC:

While I think you do have the right idea your first example function may not be named exactly correct. When I think of "setOnclick", I think that you're setting the onclick event, not firing the onclick event.

Thus, I picture this:

// reuse this same function to bind that same event to other similar buttons
toggleInstance.setOnclick(function(element) {

    element.onclick = function() {
        onToggle.fire();
        public.switch();
    }
});

If you ever need more than one control to repeat that event, you can just simply pass in that element and bind the same click handler to it.

You could take it a step further by defining the actual event handler in a separate function

// event handler is now named, so it can be easily reused
toggleSwitch: function() {
    onToggle.fire();
    public.switch();
}

toggleInstance.setOnclick(function(element) {

    // bind the event to the element passed in
    element.onclick = toggleInstance.toggleSwitch;
});

My only advice is to be careful not to over-architect. MVC is a balance, and something that's over-architected can be just as unwieldy and difficult to work with as something that's carelessly under-architected.

It's good that you're thinking about these details; they will pay dividends in the form of lower technical debt if you know what events you'll need to reuse and focus on those.

Upvotes: 2

Related Questions