Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

is it based on web components?


`<vector-graph>` itself is a properly defined WebComponent, everything else inside is just parsed as a string of pseudo-html and rendered within the parent web component (as an SVG).

Edit: note that the examples in the website, since they are part of the README in Github, are plain SVG images that have been rendered on the backend statically also by VectorGraph, see the Node.js environment if interested:

https://vector-graph.com/#nodejs


Very nice looking diagrams for the amount of effort required to make them as a client of the library.

I love that it uses exactly 1 WebComponent. I love / am vaguely confused that it doesn't read the component's own DOM but instead gets the `.outerHTML`: https://github.com/franciscop/vector-graph/blob/master/index...

I guess that it means that the actual rendering gets fully decoupled from the live, but hidden DOM tree within the WebComponent and that live DOM tree doesn't really matter aside from first render.


Thanks! That was my goal! I didn't release it officially because I also wanted to add hooks/extensibility, and that was a lot trickier than I expected. I cannot expect everyone to only use the provided tools, and extensibility was a bit tricky (there's a lot of low-level math operations going on).

I'm not totally sure what you mean by "it doesn't read the component's own DOM but instead gets the `.outerHTML`". Note that I am not a Shadow DOM expert and I made this a couple of years ago, but IIRC the reason I made it this way is that I wanted a lot of flexibility on the transformation.

It's not 1-component-to-1-svg-element, it's more like I might have an arbitrary N number of "HTML elements", which might render into an arbitrary M number of "SVG elements", some of which might even be global (<defs>) so not even in the same order as the HTML elements order.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: