🇺🇸United States @beeyayjay

Just realized that PR isn't for Mermaid itself, but an offshoot. I assume the solution would work for vanilla Mermaid too though.

Elements are added using a breadth-first search, first for referenced entities and then for referencing entities. So the order is:

1. Starting element
2. All children of starting element (elements referenced in starting element)
3. All children of first child, all children of second child, etc. to selected depth
4. All parents of starting element (elements that reference the starting element)
5. All parents of first parent, all parents of second parent, etc. to selected depth

Mermaid uses that order, but uses it's own logic to place elements on the screen, apparently with the intention of minimizing crossed connecting lines. It appears that when only one level is shown (direct children or direct parents), the focus starts with the left-most element on the screen and continues to the right as expected, but with more levels and more complex interconnections, Mermaid rearranges the elements, so focus often jumps around.

This means we can affect some aspects of the focus order by changing the way related elements are added. We could put parent elements (which appear above the starting element) first. We could also use a depth-first search, so, after the first child of the starting element, the focus would move to the first child of that child, and so on until the depth is reached or there are no more children.

I don't know if either of those options are preferable to what we have now. Neither would resolve the problem of focus jumping around the screen.

This patch looks promising: https://github.com/mgaitan/sphinxcontrib-mermaid/pull/117. It uses d3's native zoom, similar to the jsfiddle @swirt referenced in #2.

This patch implements the first suggested solution, the key only include the elements in the current diagram. I think this will be sufficient for most cases, and will provide a better user experience than including all entities.

I revised the #25 patch, to compare not just the label, but an md5 hash of the entire $definition array. It can now stop on the first cycle without the issues @msielski described. I ran it with debug code to output the definition label when it breaks out of loops, and only labels associated with the problematic modules (Fallback Formatter, and Rules) were reported, so it seems to be working as expected.

A separate array of "mapping" objects that can be referenced by other definitions as @cosmicdreams described makes a lot of sense, but this patch should prevent memory errors in the meantime.

swirt → credited beeyayjay → .