gskinner / gskinner/flutter_animate

Alternative architecture for variations / presets

Open
#31 0 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Dart
Stars
1.1k
Forks
103
PR merge metrics
No merged PRs in 30d

Description

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:
```dart
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:
```dart
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?

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.