You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason I ask is because, if using my infamous elements, there are two possible ways to animate them:
updating attributes in the declare of the elmish component, which means the animations are going through the virtual dom algos every tick.
Getting a reference and directly animating, f.e.
// suppose "el" is a reference to a motor-node,// the following would bypass the costs associated with the first method,// it is the direct path to Motor's renderer:Motor.addRenderTask(time=>el.rotation.y++)
Downside of bypassing the elmish route is losing undoableity, etc.
So there's a tradeoff with these abstractions -- we no longer have constant time updates since we need to wrap and unwrap state and actions on every tick. This isnt an issue or business logic, but if you want to get the most our of your animations, then it can be an issue. You'll loose replay-ability, but I think its reasonable to offload heavy lifting like animations into a separate system (just like CSS transitions) -- so you can specify something like "on" or "off" and let an underlying stateful layer deal with the animations. But this stateful layer should be entirely self contained.
Anyways, you can get the dom element by creating a custom React component and then h(MyComponent, props, children)
What would be the pattern for that?
(Good thing it's probably a lot simpler in elmish than in elm since it's just JS).
The text was updated successfully, but these errors were encountered: