Parsers deconstruct chunks of HTML into a consistent data structure.

Code can get very complex, especially on websites with high levels of functionality and interactivity. When your views get cluttered or if you must re-render markup in a function callback, the parser is a useful pattern for abstracting your transformations into reusable, bite-sized chunks.

What is a Parser and Why Do They Matter?

Parsers are responsible for transforming a predictable chunk of DOM into a consistent data structure. For example, we could create a parser that takes a list of products and turn them into a JSON-like API.

Below is a rather simple example of having a Product List Parser used in a PDP page:

// product-list-parser.js
// This is what a parser itself might look like.
], function($) {
    var parse = function($container) {
        // construct a context object...

        return $container.find('.product-item').map(function() {
            var $item = $(this);
            return {
                id: $item.attr('id'),
                title: $item.find('.title'),
                href: $item.attr('href')

    return {
        parse: parse
// pdp-view.js
// This is a parser looks like when used in a view file.

// ...

context: {

    productList: function() {
        return productListParser.parse($('#product-list-container'));
    // productList() => [
    //    { id: 'product1', title: 'A Thing', href: '#' },
    //    { id: 'product2', title: 'Another Thing', href: '#' },
    //    { id: 'product3', title: 'One More Thing', href: '#' }
    // ]

// ...

With this methodology we can see that parsers help keep code legible and easier to maintain. Manually modifying DOM can be a complex and heavy handed endeavor, so it's easy to imagine having all of that code in a single view file can be very difficult for maintainers to groc.

By abstracting all that code into parsers, we keeping our view files clean and simple while also keeping our code DRY and reusable. On top of that, by having context objects to work with, we give our Engineers and Developers greater control over how components and templates can be built.

How are Parsers Different From a View?

On the surface, views and parsers may appear similar in purpose: take DOM and return a context object that is eventually consumed by Dust. The fundamental difference between the two is that a view is passed an entire desktop page, but a parser is passed a pre-selected arbitrary chunk of DOM.

Other differences include:

A view can be thought of as a place where you store content from the original desktop page, and can make direct transformations to the desktop DOM if needed. Views have additional responsibilities and functionality, such preProcess(), postProcess() and so on. Lastly, the view is only ever run once: when first arriving on a page.

In contrast, parsers can be thought of as a small, reusable form mold that can be used anywhere you need to bend chunks of HTML to your will. Parsers do not directly make any changes to the provided DOM, it only uses that DOM as a data source for the construction of the context object. Parsers typically have only one method, parse(), and can be run as many times as needed, usually in views and UI scripts.

When Should I Use Parsers?

Under the following conditions is when it makes the most sense to use a parser:

Where do Parsers Belong?

Put very simply, parsers belong a /parser directory in either the page directory that they are used in, or if they are used in many pages then they should live in the global directory.


Naming Convention

Parser files should always be suffixed with -parser.js, and when requiring a parser into another JS file, it's variable should be based on the filename prefixed with location identifiers when necessary (such differentiating similarly named parsers).

// pdp-view.js

    // ...
    // ...
) {

    // Notice how we prefixed both rating parser variables with the location
    // they came from to help differentiate between the similarly named parsers.
    // This could happen because, perhaps the `globalRatingParser` could be for
    // user review ratings found throughout a site (ala BazaarVoice maybe), but
    // the `pdpRatingParser` is for ratings found for individual products on
    // that product's page.

Edit in GitHub