Alternative architecture for variations / presets

[esDotDev]

The current approach to effect variations / presets has some drawbacks. Use shake as an example.

• shakeX and shakeY variations exist, but only in the form of method extensions
• This favors the extension syntax, and does not provide access to these presets using declarative syntax, ie, we can not do: Animate(effects: [ ShakeXEffect() ]). This is confusing / annoying.
• As more variations are created, this will build up more and more functionality that is closed off from the declarative syntax.
• It will become a mish-mash of EffectName and effect.variations(), for example, you might have .fadeIn() and FadeUpAndIn both existing. With the class FadeIn not existing... quite weird.

Instead of using extension-method-first approach, a more component-based approach could be adopted. This would standardize the API, and not favor one syntax over the other.

psuedo code, eg:

class FadeEffect {} // core effect, adds .fade() extension

// presets/defaults are defined in the class
class FadeInEffect {
   build() => FadeEffect(begin: 0, end: 1)
}

// extension method just uses the class
extension FadeInEffect on Animate {
   fadeIn() => this.addEffect(FadeInEffect());
}

With this approach the presets are defined at the class level, the extension methods can still exist, but now the declarative form is also unlocked. There will also be no mish-mash, as everything will exist both as a FullEffect and .extensionEffect

Non Breaking

This approach would be non-breaking as the existing extension methods would continue to exist, they would just be augmented an additional syntax for their use.

eg fadeIn() still exists, but now there is also FadeInEffect.

Composition

More complicated presets need to support composition. Not sure exactly how implementation would look, but conceptually we want one effect to be composed of two or more core effects:

class FadeInUpEffect {
   build() => FadeInEffect(
      ...
      child: SlideInUpEffect( ... ));

   // adds .fadeInUp() extension 
}

The fundamental design challenge here is: How can 1 effect use 2 or more other effects? Is this even possible with the current architecture?