Should there only be one controller per page within a JavaScript-based MVC architecture?

Question

Let's say that I create a page in my marketplace web application where buyers can see a catalog of all products offered by some or all sellers or sellers can see just their own products in a preview of this buyer's view.

Within my JavaScript code I would create a model object that synced data with the server, one or more view objects that would render various pieces of that data to the user and a controller object that routed messages between the model and views.

Now let's say I create another page in my application where a buyer can see a catalog of only the products offered by a single seller (yes, this is just a subset of the above functionality but just go with me on this for the sake of this hypothetical). In this case, though, the catalog exists on a tab on the page with sibling tabs that contain other unrelated data.

If I were to reuse all the objects I created for the first page, would it still be feasible to call the "central" piece a controller when it would be included in one tab of a page that would probably have its own controller object? Or would it be more proper to stick with a single controller per "page" and just call this some sort of view object even though its purpose remains to route messages between its own internal model and views?

The crux of my query is whether from a conceptual standpoint there should only be a single controller in the JavaScript code for a single page or whether abstracted component units can have their own MVC architecture hidden away from the page's larger MVC architecture?

Answer 1

It really depends on the structure of the page. If a page has only one purpose and one concern, then you should try to use a single controller so that the code is grouped logically.

If there are multiple components on a page with different concerns, then you should absolutely use multiple controllers for the sake of decoupling.

For example, consider a page that has a body that tracks products by a seller and a header that tracks the user's information and login session. The controller for the seller's products should hold logic about prices, stock reporting, discounts and so forth. Giving that controller power over logging the user out, or changing their password, dilutes its purpose and makes it less reusable. On the other side, giving the user controller price information about the seller's products is useless when you switch to a page about shipping arrival dates.

At the heart of it, this is just a higher-level version of the encapsulation discussions that go 'round and 'round the OOP world. One section of code, one purpose, no meddling without explicit permission from the code in question. This prevents code duplication, code corruption, and strange side-effects. It also makes the code much more maintainable when you only have to reason about a single topic when looking at a specific section of code.