Using Redshift with virtual-dom

[ArnoBuschmann]

Hello, your project looks interesting 👍

Now as you say Redshift

... provides DOM support for ease-of-use but provides the ability to work with raw numbers and custom callbacks for total creative freedom...

...I wonder, what would be the best practice to use Redshift in conjunction with virtual-dom (which does its own dom updates/diffing) -> https://github.com/Matt-Esch/virtual-dom

I'm using virtual-hyperscript (provided by virtual-dom) to create a so called vtree, a representation of virtual dom nodes, which are updated/diffed with the real dom -> https://github.com/Matt-Esch/virtual-dom/blob/master/virtual-hyperscript/README.md

[mattgperry]

Hey man, thanks for checking out Redshift.

With any new framework the best way to integrate Redshift is going to be a matter of exploration, and perhaps when things become more standardised, a new route plugin will be created for it.

However I've just taken my first quick look at virtual-dom and I've rewritten the example there to a version that uses Redshift.

It's a fairly crude example, more sophisticated patterns will emerge, but it should show how you can still use the virtual DOM to render while Redshift drives the properties it's rendering from. The example here also has the added advantage of using Redshift's unified rAF loop, which will bring some performance benefits.

Let me know if you have any comments/questions!

[ArnoBuschmann]

Good morning. Thanks a lot for the examples, it looks awesome! Comparing both examples, while setting the first ones interval to a minimum, the Redshift one looks a lot more performant indeed. Do you have a general guess about the performance gain? I'll go and play with it later today and tell you, how it works out.

While having a look at .addRoute(), I noticed there is a route for svgPath which made me wonder: Would it be possible to generate an effect with Redshift, that is comparable to Greensocks DrawSVGPlugin?

[mattgperry]

Yeah man, excellent spot :)I haven't documented it properly yet, because I haven't done robust testing of that feature. And that route should just be called 'path' so I'll update the docs in a minute. But yeah, in theory you can manipulate SVG paths in the same way as DrawSVGPath by using the length and offset properties. These take percentages, by the way.

The performance gain isn't necessarily to do specifically with execution time. Two identical blocks of code will always run at more or less the same speed. The difference with requestAnimationFrame is 1) that it syncs page updates to monitor refresh rate, which makes everything smoother and 2) doesn't run in the background, so it won't drain laptop/phone batteries.

Also a great performance gain compared to that example would to limit the properties you animate to transform and opacity wherever you can. They perform much better on mobile, as per http://csstriggers.com/ (properties with a purple dot are bad)

[mattgperry]

@ArnoBuschmann I'm having a few troubles publishing on NPM at the moment, but I've just pushed a fix for the svg path route in version 1.1.3. The redshift.global.min.js file is updated but NPM will probably be tomorrow.

You just have to set dom to your path element and you can animate the opacity, width, offset, length, spacing and miterlimit properties ie

yourAction.play({
    dom: document.getElementById('yourPath'),
    path: {
        length: 100
    }
});