My opinion is that we shouldn't (at least by default) - React, Virtual Dom and "smart" D3 components would benefit in terms of efficiency if the dom structure is already there and the node is addressed repeatedly.

@janesconference it would not be an issue when the same resource is addressed into a node, because in that case the node is currently not cleared.

We currently clear the node when we change the resource addressed into it. But in some cases, fragments of the html in the node are the same (they do not change structurally), and depending on how you are doing the rendering, you might get a brief flicker.

So the question is: do we clear the node when a resource has changed, even when there might still be some html we can re-use?

@grancalavera Thanks, I was not remembering well (I thought it was cleared anyways).

So, to summarize, the pro [cons] are:

• Clear node: the node not having structural residues of the latest resource is more "what the user expects" and avoids writing additional code to clear the node, if needed.
• Don't clear node: can help performance-wise in some cases (similar structures) and can avoid DOM flickering when quickly readdressing (depending on how the resource's component re-render).

Could you think of some other pro/con?

Proactively clearing the DOM seems a bit intrusive to me. I think we should probably just stick to dispaching an event and leave it up to individual views to decide if they want to clear the DOM before rendering

@aaronhaines +1.
I was thinking that if we use react or virtual-dom, replacing the DOM is handled automatically by the render layer. If we use d3 or vanilla, we have finer-grained control over what's happening.

Sorry I missed this conversation (despite us talking about it offline @aaronhaines!) because apparently I wasn't watching the repo – my bad!

It's an interesting conversation and I don't necessarily think the answer is that clear cut. I don't necessarily think it's a good argument to not clear because some DOM may be shared, because there are any number of reasons why that DOM may be shared and unless the component is truly smart there's a very real risk we'll just be muddying things up. That said, I think it may be useful not to clear such that you can address multiple resources into the same node, as siblings, without requiring wrapper elements. The specific case that precipitated this discussion, or at least the case I saw, looked to me like actually it shouldn't be the one view being addressed, but multiple. This could either be done by composing resources, or by addressing multiple resources at the same time – the latter however would require wrapper elements unless there's a smart way to make these views siblings.

@gabrielmontagne I believe you were part of the discussion we had re: this way back in the day, and if I recall correctly you were also involved in making whatever change we came up with then – do you recall what we did and the rationale behind it?