Reasons for the 0.3.0 changes

This is an old guide to upgrade from 0.2. to 0.3.0. Please refer to the Home page to upgrade to the newest 0.4.0.*

Definitely not mandatory reading! But if you're curious about the thought process behind these changes, here's the list of reasons that corresponds to the changes listed in the full details page.

1. The component might do more than just spring physics in the future (we might enable decay physics!). Motion is a more agnostic name.

2. Following point 1's explanation, a decay physics lets you specify speed rather than the final value; in this case, style(s) and defaultStyle(s) are more agnostic names since there's no "end value" to specify here.

3. Recursively animation a sub-collection was expensive and error-prone due to the various behaviors of wrapping stuff with val. It's also hard to type check and prevent future API possibilities (e.g. RM will be able to recognize your height prop and animate correctly to integer precision).

4. Easier on the eye. Also, your current code without the spring helper naturally still works; but in the future, we might turn that structure into something truly opaque, e.g. {_springVal: 10, _springConfig: [120, 17]}. You won't have to read into it, not even in render. See next point.

5. Why not? Now that we only interpolate the first level of your style object, we can safely strip away the implementation detail of val and config. Works great in tandem with the spring helper.

6. The use-case for an array was because we naturally supported arbitrary endValue formats. No need to support it anymore. As much as possible, we'll push people to pass data instead of a function, since the data won't change and can be cached. An endValue function had to be called each frame since we don't know what the new value might be.