How do you handle complex JavaScript objects on the client?

Question

EDIT: I am going to break this into two more specific questions.

I am trying to understand best practices and patterns for client side JavaScript development. In particular, what do you do to manage more complex data models on the client?

As an example, say you where managing some sort of store catalog online, and had a Product, with it’s pretty typical properties: { id, description, price, etc… }. But the product also has a set of categories that it could be associated with, and therefore two more lists needed to be fetched: AvailableCategories and AssociatedCategories. Of course, to make matters more complex, your association of categories to tables is not a simple join, but has meta-data like a scalar number from 1-10 that describes how strongly associated the product is to the category. And then say there are four or five other associations, of which one has an “Available” table that might require paging (for instance, maybe you associate the product with something that has a million items in the table, and you want to pull down only 100 of them at a time, searchable and sortable, of course).

My point is, there are lots of models, along with join associations with meta information, some data can be pre-fetched or statically downloaded on the page load, while some has to be dynamically fetched. And of course, you don’t just want the base models, but “observables” as well, so that if someone chooses a color to associate with your product, you would be notified (for free) someplace else on the page of the changes.

I am thinking of moving to a client side MVC framework, like SproutCore, but would like to see some lighter weight options and patterns. I would appreciate hearing what you use, why you use it, and any other thoughts on this problem space.

Thanks.

Answer 1

When I build javascript apps, I don't start by looking at the data model, but rather the user interactions that the app will support. Then I design those interactions by making very specific ajax RPC calls that only populate exactly the view I'm looking at. Same with the operations in that view, I have very specific ajax RPC calls that does exactly what that view requires.

In some cases I do end up with more generic RPC calls, where more views can share similar data, but I refactor that when I reach it, I don't start modelling like that.

So far I typically, as you say, have some static categories etc to read up at start of the application, but I've managed to avoid having huge complicated cached data models in javascript memory that needs syncing with the backend.

In this I've found the MVP pattern to be a much better choice than MVC - driving all my application code with events.