How to organize the code for a javascript UI widget?

Question

The web app I'm working on has several fairly complex and stateful pieces of client-side UI. I'm trying to keep things sane by organizing them into composable javascript widgets. Some of the requirements are:

1) Some of the data required to initialize the widget needs to come from the server
2) Some of the data comes from the client (based on which of a list of items is selected)
3) The state of some sections of the widget needs to be remembered when it's closed and reopened
4) The state of other sections needs to be forgotten and reset to the original setting
5) The page has to fully render very quickly, so AJAX calls need to be minimized

So, my question is, how do you organize the code for this widget? What I have currently involves sending down the HTML for the widget with some data (i.e. #1) filled in on the server side (to avoid sending down the data via an extra AJAX call). I then have a bunch of jquery code that fills in the client side stuff in an ad-hoc fashion. And then more code to reset everything back to the desired state on the second invocation. Surely there's a more declarative way to accomplish this?

Answer 1

I think you would be very happy using Javascript MVC. It makes it much easier to manage the state of components, and makes it pretty easy to manage data on the client side instead of making repeated ajax calls. Do the tutorial and I think you will be quite happy.

EDIT

My original answer doesn't address the page rendering speed.

If you are really worried about page rendering speed, the best solution is to render the document. The next best solution is to not worry about the problem until the final stages of development. It is pretty easy to optimize data loading behavior, and you will come up with much better solution after you have solidified the rest of your application design.

I have employed various techniques to improve render performance, such as cachable ajax, or injecting script blocks with data when the page is generated on the server. Both of these approaches have given me significant performance boosts, and both were easily applied at later stages in development.

Answer 2

If you're going to roll your own widget, and you're going to persist the state of the widget, then assign each widget a GUID/UUID and use that as part of the "container name" of the widget (I take the last 13 digits for mine to ensure some sort of randomness. I don't maintain that it won't ever break.) You can do that part easily enough during object creation, either serverside or clientside. You can persist the GUID/UUID as the ID of the widget as well, so that isn't likely to ever change.

All this was given as part of "how do I compose the widget" for modularity sake, especially during javascript operation (the italicized section is what I thought was meant... further conversation leads me to believe that I may have been wrong. leaving it for posterity now)

Otherwise, see the comments above.