So....Yeah....this part is a little confusing now that you mention it. The super-secret-sauce here is that the `_getViewCfg` here passes in a reference to the filter object on instantiation. That object may or may not have data in it regardless of what we actually want to render based on the state so we need an external trigger to tell the charmbrowser what it should actually be rendering regardless of what data is available. 

This could probably be refactored to make it clearer as to what's happening (this was the same technique as was used in the old code) but I'd like to push that until after this refactor and caching.