Monday, June 9, 2014

Easy Snap.svg Translations in Polymer

I believe (hope) that I am ready to connect the pieces of my custom <x-pizza>Polymer element with Snap.svg.

Yesterday, I learned that Snap.svg operates on <svg> tags instead of my beloved <div> tags. Actually, <div> aren't beloved at all—I'm just trained via much heartache to keep throwing more and more <div> tags at a classical DOM problem until something works. Trained so much that I instinctively do so even when the situation does not call for it. Anyhow…

I am loading SVG assets into a svgContent object inside the <x-pizza> element. After last night, I put the base pizza SVG content inside a <div> then Snap() the newly innerHTML'd <svg> element:

(I also switch the maker code to return a Snap.svg element instead of a node to make that work.)

That is really only a minor improvement over the previous raw SVG coding. What might make it better is eliminating all that ugly string concatenation. Short of pulling in yet another JavaScript library, I am not going to get string interpolation. But Snap.svg does give me a Matrix object that can translate an element. Y'know… with numbers:

Aside from the rest of the code that randomized X-Y positions over a circle, this code is pretty clear. It lost some unnecessarily verbose DOM coding as well as string concatenation, which counts as a win. And, the <x-pizza> element still works:

With that, the full <x-pizza> element is using Snap.svg—except for some animation code, which I will convert tomorrow. So far, the conversion from raw SVG to Snap.svg for <x-pizza>'s assets has been nice, but not a huge win. I am hopeful that Snap.svg will really shine with said animation code—my current implementation is truly awful!