search

chenglou / react-state-stream

React animation on steroid.
362 stars 19 forks source link

Declarative touch interactions #10

Open KyleAMathews opened 9 years ago

KyleAMathews commented 9 years ago

Perhaps out of scope for this project but lots of interesting ideas http://iamralpht.github.io/constraints/

gaearon commented 9 years ago

That's rad

chenglou commented 9 years ago

I really like the idea. But which part specifically do you think relates to the idea of a state stream? Genuinely curious!

KyleAMathews commented 9 years ago

Just that both are declarative animation libraries. It'd be cool to have something like the above library built on top of react-state-stream.

chenglou commented 9 years ago

I'll keep an eye on the its progress. But I think we're at odd as to how to approach these things here. The constraint approach essentially still treats animation as a non-observable, instant transition between 2 states (kinda like CSS). Under the hood, it could be implemented with state-stream, yes. But the goal of state-stream is to be an idea rather than just an implementation detail (if it was just an implementation detail, then trust me, I would have picked some more performant way to approach animation).

While we're on this topic, I'm wondering how the concept of state stream work with events. I need FRP people's guidance here since I only casually dabbled in FRP.

kof commented 9 years ago

@iamralpht

iamralpht commented 9 years ago

I'm not sure I totally follow the design here, but the system of linear constraints in slalom just constraints the universe of possible states in a state stream (and the universe is still infinite, it just maybe isn't continuous depending on the constraints and how other objects/variables are positioned).

Because the touch input and physics simulations get run through the linear constraint solver, they're completely live and observable--and feedback into the system is provided (basically) by motion constraints observing if they are being violated and then backtracking the constraint solver to find the cause. Currently the external variables are almost always bound directly to DOM/style, but that won't be the case for more complex usages.

I don't think state stream really helps the constraints work though, because that already assumes a more physical DOM (e.g.: in my photos example, the photos are already present and laid out horizontally; I haven't worked on virtualizing long lists or anything like that).

I'm also a bit confused with some of the descriptions of state-stream: in the photo example where the transition between photos is controlled by a gesture, what happens if you drag to the left, then to the right in the same gesture? Now you're unmounting one of the components that you were also mounting... I'll keep reading though, it's interesting to think of animation as a map over the infinite range of possible values.

chenglou commented 9 years ago

@iamralpht we're in agreement, lol. State-stream and most other systems can implement yours, but conceptually they're different. Mine's more low-level and can possibly do more but I think for lots of animations people would prefer the constraint system (?).

Mounting and unmount is a react (and react-like systems) problem. Doesn't have that much to do with animation. Sorry it confused so many people (it's in this repo because that's how I communicated the whole solution to the react team. I'll clean it up soon. (But if you check the last example of the demo now: re-mounting does work).

iamralpht commented 9 years ago

OK, that makes sense.

The constraints work only handles a certain class of touch interactions (it ends up being a pretty big practical class, but it's not universal), so it's not intended to be a generic animation solution. Can't wait to see how state-stream develops!

Mount/unmount kind of scratches at the core of MVC for me, but that's a much longer conversation :).

chenglou commented 9 years ago

Core of MVC? Care to explain?

iamralpht commented 9 years ago

Yeah! Specifically animating list operations (particularly delete) is an area where we typically have the view perform a transition after the model has changed, so during the transition the view is no longer directly reflecting the model. When multiple removal or addition transitions overlap it's easy to make a mistake because of this (the Google GMail app for Android frequently glitched things around under these circumstances).

The mount/unmount transition work is abstracting this pattern and is one of the nice juicy problems in modern MVC :).

chenglou commented 9 years ago

We have some talking to do lol, https://twitter.com/_chenglou