Re: [css-houdini-drafts] [css-animationworklet] Verifying the StatefullAnimatior/StatelessAnimator superclass on prototype chain (#850)

The decision to use two superclasses was made in F2F and discussion is [here](https://github.com/w3c/css-houdini-drafts/issues/812#issuecomment-417053903)

To summarize the options we considered was:

a. Having a static attribute on the class. This was considered not to be that ergonomic
b. Looking at the shape/number of constructor argument. This is not well supported by JS.
c. Use two super classes: This is the one we choose but even at the time I and others were concerned about its ergonomics [1].

I think we do have another option to do this that is both ergonomic and practical: Use existence of "state" getter to indicate that an animator is stateful. We do expect stateful animators to provide a state getter so let's make that the condition.

```js
// Stateful
registerAnimator('a', class {
  constructor(options, state) {}
  animate(currentTime, effect) {}
  // The fact that there is a state getter means indicates this is a stateful animator
  get state() {} 
});

// Stateless
registerAnimator('b', class {
  constructor(options) {}
  animate(currentTime, effect) {}
});
``` 

This is more ergonomics since it does not require a superclass, much easier to spec and implement, consistent with how we require and check existence of `animate` function, and requires less work on the web devs part since they are already writing state getters anyways for their stateful animators.

One argument in favor of using superclass was that in future we may use it to have other methods, attributes but so far we don't have anything like that. So having a better ergonomic API now is better that some potential future benefits.

[1] <dael> majidvp: Okay....you're using a heavy hammer for something that could be an attribute. Attributes are very common.




-- 
GitHub Notification of comment by majido
Please view or discuss this issue at https://github.com/w3c/css-houdini-drafts/issues/850#issuecomment-459408013 using your GitHub account

Received on Thursday, 31 January 2019 16:25:08 UTC