More lifecycle hooks for top-level components.

[prook]

I've been playing around with on-the-fly D3 vizualizations: Changes to data are announced by server via a WebSocket notification. Upon receiving the notification, clients may download a fresh dataset, and update their vizualization.

The WebSocket needs to be opened at some point while initializing/mounting the viz component, and also needs to be closed when unmounting. I have been able to do this by wrapping rid3/viz into another component to manage the WS state, but it feels like a slight bodge.

It seems more lifecycle hooks, say for the :svg element would make these need-cleanup scenarios easier. However, while pondering whether the whole WebSocket idea is not overly complicated, I started to wonder if the lack of said hooks was not intentional.

So basically:

1. I'm seeking your thoughts on adding more top-level lifecycle methods (in :svg hash-map most likely), and
2. if that seems like something rid3 would benefit from, I may cook up some patches.

[gadfly361]

@prook Thank you for opening up this discussion! I think that is a fantastic question.

I think ultimately it comes down to a matter of taste, and so the following is just my personal preference:

I agree with the recommendation by re-frame that using lifecycle hooks to load data is overloading the responsibility of the view layer.

So if your preference is to start and stop websocket via lifecycle hooks, to proceed with with wrapping rid3/viz in another component, even though I do agree it is a slight bodge. The reason for this is because I would prefer to limit the surface area of rid3 if possible and other (not-too-painful) solutions exist.

Anyways, just wanted to give my initial take on this topic, but I am happy to discuss it further.

[prook]

True, data retrieval seems inappropriate in the view layer.

But what about something bound to the view more tightly? d3-force simulation, for instance. Lifecycle of js/d3.forceSimulation should be pretty much bound to rid3/viz's, and the sim should be invisible to the world outside the component as well. The simulation should initialize on component mount, update nodes/links/whatnot on rid3/viz's ratom change, and stop on component unmount. I think no matter what solution to d3-force sim I (we?) come up with, the finer lifecycle control may be needed.

I didn't mention d3-force initially to avoid digression, but now it seems unavoidable. Also, I thought finer lifecycle control could be good for other scenarios as well, but I fail to come up with examples (and if I do, they're easily dismantled) -- all lifecycle work not related to D3 (e. g., WebSockets) can be done outside rid3.¹

But D3 stuff cries to be in rid3, doesn't it?

So the question is, are there any other parts of D3 toolbox that could use finer lifecycle control? Or will this boil down to finding how to implement d3-force properly in #10 (and the digression was this whole issue)?

¹ And also it gave me -- well, gives me -- quite a headache to figure out a how to plug in the simulation. I've found a few solutions which do work, even with GUP and nodes properly merging in the sim object, but they are hairy to say the least.

[gadfly361]

@prook Thanks for following up!

I think you have convinced me that we should open up the api and add more lifecycle hooks to things like svg.

So if you are willing to cook up some patches for that, I'd be happy to review it!

---

Also, regarding force simulation specifically #10 , I haven't had time to look in to that. If you have a minimal, working example with rid3, it would be nice to see ... and then more to the point, we can brainstorm on what we can do to improve it!