From SVG to Canvas – A new way of building interactions

From SVG to Canvas – A new way of building interactions
felt.com

Maybe I'm an idiot though - where is this library? I can't find it on their GitHub or linked from the articles

> In the SVG world, we use CSS z-index to place the DragBox at the back and the SelectionFrame at the front.

Not a great start IMO - SVGs don't support z-index. The front-to-back ordering z-index influences in HTML is decided in SVG directly by the order in the HTML within the element (in reverse - later elements are "on top"). What they could mean to say, if this isn't entirely inaccurate, is that "we render multiple SVGs and arrange them with z-index", which... I also find strange. I don't want to read their source code but I also don't find this to be giving them huge credibility.

> Performance

> Having every element produce a whole load of DOM elements for React to manage becomes a problem for performance when every element attaches event handlers, has to manage their lifecycles, observe state, etc., etc.

My concerns are mounting. This is fundamentally the problem React solves, not one it creates.

The amount of layers they picture in their example is not huge. I had the target to get 60fps on a Graph with 1000 nodes + smart edge routing, and you can do lots of interactions in the graph - each node can be moved independently or in a group, selected, you can drag a background box to select objects geometrically intersecting, and you can create new connections with drag, you know - basics. Not sure how performance is impacting them at an order of magnitude less, unless they are struggling with React itself.

> Interactivity Limitations

> with the text taking up so much space it’s very easy to accidentally drag the text instead

> This was a very longstanding bug

I interpret this as them saying "the text background was not displayed to users, so while it appeared the mouse was over the polygon, it was actually over the text background, therefore the text was dragged". Seems to me hover state would give the user the hints they need here, but I look forward to the Canvas solution

> Maintainability

Once again I really can't help but interpret this as a weak handle on React.

Onto the solution.

> The new system: per-state InteractionHandlers

Honestly, the fact they had to leave React to manage this once again speaks to bad React practices. Have they never heard of Context/Provider?

> The general idea is this: there are a lot of different things you can do in Felt, but at any given time, the number of things you can do is limited. If we can therefore define which interactions are active at any given time, and also manage the flow of events through the handlers we should be in a good place

Yes, this is good architecting. However, the only thing they describe here that piques my interest is this:

> Here is the full sequence of events that an InteractionHandler can process, with the ability to break the chain at any point, and prevent other handlers in the stack from being called.

>

This is a big pain point in React - very difficult to manage onMouseDown separately from onClick. Usually I accomplished this by overloading onMouseDown and onMouseUp to call the actual dev-user-available action handlers, but their described result is more graceful.

> Goal 1: Interactions should be decoupled from each other

> Each interaction handler has no knowledge of any other. The knowledge about how to prevent “collisions” in interactions resides with the map of handlers and the manager.

Right, but why couldn't this be done in React?

> Goal 2: Interactions should be performant

> Because there is only one handler per feature as opposed to a bunch of handlers per element, there is a lot less allocation of resources.

Sounds and looks cool, is the implication that there is only O(feature count) event listeners for the Canvas?

I'll have to profile my library for this

> Goal 3: Interactions should be decoupled from access control

> Access control is now simply a case of writing a different list of interaction handlers for each access level. There’s no longer any isEditor code littered throughout

> Goal 4: Interactions should be decoupled from rendering

Yikes. I think they really conflated bad architecture with React problems a lot in this article.

Alright though, I see some clear wins at the end:

> Goal 5: Complex interactions should be achievable

>

This is a win, and one they obviously wanted. It's probably true this isn't possible with the DOM, unless you render each character individually as a polygon or something that would undoubtedly be insanely painful

> Doing this with an element-centric approach is nigh-on impossible. There’s no way (as far as we know) to say to a DOM element: “receive clicks, but pass-through mousedowns and drags.”

I agree with this claim, but wish they would elaborate what these use cases look like.

> OK, there are some hidden details there such as ...

> we maintain a spatial index of our elements using rbush which we query for coarse intersections with the cursor before performing more accurate hit tests using Turf.js.

Right, this all sounds quite graceful, indeed it sounds a bit like implementing a graphics system. It sounds like it met some of their goals too, and enabled some long-desired features the DOM didn't make possible.

But their criticisms of React & SVG are really weak here, and it sounds to me like they never properly decided how the system should behave and what parts should interact in the DOM world, and their issues fell out of that.

I also think that you should really not talk so much about z-index with SVG unless you make it more clear how those things could even be related.

Overall, I think they had a great team that implemented a great solution that aligned with their end-goals, but the work they replaced doesn't sound like it was even well-aligned with the framework it was implemented in, let alone their end goals. I would not agree with their recommendation to move to Canvas if SVG doesn't "feel right" until you do more analysis of why your solution is failing and what options are available.

I'm kind of waiting for webgpu to reach 95+% browser support before switching though.

If I do all the work of switching, SVG better not get gpu/hardware-acceleration support the next day

This is a great example of "fighting the framework". React + SVG got them from nothing to a working product. But then they had to rewrite completely to solve problems in the product because the framework no longer fit the product. I've seen this so many times.

But it's hard for people to believe when they start out and choose the "perfect" framework for their product:

"you will eventually have to rewrite your entire product because that's easier than fighting the framework to make it do what you need"

"no, we won't, this $framework is flexible enough to do whatever we need"

"OK, good luck"

2 years later:

"we're rewriting the product completely because $framework wouldn't let us do $thing"

Not that I'm advocating for not using frameworks, just for people to realise that eventually (almost) everyone fights the framework and rewrites. And the more the framework does, the earlier the fight begins.