The new bug listings listings were the first time my squad, the Orange Squad, had a chance to work on some really nice in-depth client-side UI since our squad was formed. Not only were we implementing the feature, we wanted to lay groundwork for future features. Here are some of the new things we’ve done.
Synchronized client-side and server-side rendering
It’s been a mixed bag. We did accomplish the goal of using a single template across client and server, but there are significant bugs on both sides.
mustache.js also has bugs that cause it to eat newlines and whitespace, but those can be worked around by using the appropriate entity references, e.g. replacing “\n” with “ ”
The Python implementation, Pystache, does not implement scoping correctly. It is supposed to be possible to access outer variables from within a loop. On the client, we use this to control the visibility of fields while looping over rows. On the server, we have to inject these control variables into every row in order for them to be in scope.
Client-side Feature Flags
While in development, the feature was hidden behind a Feature Flag. But at one point, we found we wanted access to feature flags on the client side, so we’ve now implemented that.
History as Model
We wanted users to be able to use their browser’s Next and Back buttons in a sensible way, especially if they wanted to return to previous settings. We also wanted all our widgets to have a consistent understanding of the page state.
We were able to address both of these desires by using YUI’s History object as a common model object for all widgets. History provides a key/value mapping, so it can be used as a model. That mapping gets updated when the user clicks their browser next and back buttons. And when we update History programmatically, we can update the URL to reflect the page state, so that the user can bookmark the page (or reload it) and get the same results. Any update to History, whether from the user or from code, causes an event to be fired.
We’re able to boil the page state down to a batch identifier and a list of which fields are currently visible. The actual batches are stored elsewhere, because History isn’t a great place to store large amounts of data. For one thing, there are limits on the amount of data that can be stored. For another, the implementation that works with old browsers, HistoryHash, can’t store anything more complex than a string as a value.
All our widgets then listen for events indicating History has changed, and update themselves according to the new values in the model.
It’s been an interesting feature to work on, both because of the new techniques we’ve been able to try out, and because we’ve been closely involved with the Product team, trying to bring their designs to life. We haven’t quite finalized it yet, but I’m going on leave today, so I wanted to let you know what we’ve all been up to. Happy holidays!