That said, the way this notebook is setup, it’s very difficult to develop in Observable because it uses mutable state extensively: each cell modifies the SVG element returned by the svg node rather than creating new (“pure”) DOM. Give me a moment to refactor it to make it a little easier to debug.
Here’s a version with minimal refactoring that works in the Observable style. Instead of a cell having a side-effect where it modifies the SVG element defined by svg or g, each cell is a function that is passed the element you want to modify. So, if you change the function definition, the entire SVG is thrown away and re-run, and you get the expected result.
Following Mike’s lead — here’s a version with additional appendLines() and appendTurtles() functions defined, as well as a draw loop that calls model.step() and yields the SVG node.
Hey Jeremy, a small simplification is possible in your implementation: there’s no need to join .data(model.links) and .data(model.turtles) in the draw() step, as the binding is made directly with the turtles
There is one last oddity: one of the turtles does not draw! Probably the first or last, haven’t tested for that yet. The links connecting to the “invisible” turtle work fine so it’s “there” but just not drawn.
Set your override’s number of turtles to 2 and it will be obvious.
the reason is that the append('defs')… classes polygon as .dart; then, the data join being made on selectAll('.dart'), the first turtle is joined with this defs>g>polygon and you get n-1 use
