Jan Odvarko: Firebug Internals I. – Data Providers and Viewers

Пятница, 28 Марта 2014 г. 17:35 + в цитатник

One of the achievements of Firebug 2 alpha 1 release has been adoption of new JSD2 API and this task required significant changes and improvements in our code base. Among other things, we have also introduced a new concept that allows to nicely build asynchronously updated UI.

There are other concepts in Firebug 2 and this version is with no doubt the best one we have released. Try it and let us know how it works for you (Firefox 30+ needed).

In order to implement remote access to the server side debugger API, Firebug UI needs to know how to deal with asynchronous update. We applied Viewer Provider pattern and extended it with support for asynchronous data processing.

If you like using Document View, Model View Controller or similar design patterns to build your code base, you'll probably like Viewer Provider too.

So, follow this post if you are interested to know what Viewer Provider looks like.

Viewer Provider

This design pattern represents a concept of data providers that mediate data access through an unified interface. Providers are usually consumed by Views (or Viewers) that use them to query for data and asynchronously populate their content when results are available.

First let's see simpler, but related Document View pattern:

View is responsible for data rendering
Document represents a data source

The problem with this concept is that View needs to know the interface (API) of the Document. This makes it hard for the View to switch to another data source, in other words, it's hard to reuse the same View for other Documents.

An improvement of this simple concept is incorporating a Provider in between the Document and View. The provider knows the Document API and expose them in unified way to the Viewer.

Provider provides data through unified interface

There is typically one provider for one specific data source/document, but in complex application (like Firebug) there can be even a hierarchy of providers.

Having data providers implemented for various data sources means that existing viewers can easily consume any data and can be simply reused.

Here is how Provider interface looks like:

hasChildren: used mostly by tree-style viewers that needs to know whether a twisty (+/- icons) should be displayed for specific item or not; It's implementation can be simple, as you can see in the code or optimized for various scenarios.
getChildren: returns a list of child objects for the given object
getLabel: returns a label for the given object; The label will be directly displayed within the UI (e.g. in a drop down list). The col argument can be used by UI widgets supporting tabular data display (several labels for given object/row).
getValue returns a value for the given object

Asynchronous Viewer Provider

One of the challenges when consuming data is support for asynchronous processing. Especially in case on web applications toady. If you need a data you send XHR and wait for the asynchronous response. Viewer and Provider pattern has a solution fort this too.

getChildren returns a Promise instead of a direct list of children. The promise is resolved asynchronously as soon as data is available.

The main difference is that getChildren returns a Promise. The solid line (on the image above) represents synchronous data querying, the dashed line represents asynchronous update. The promise object usually comes from the data source and is passed through the provider to the view. Of course, the update happens when queried data are available.