Jochum van der Ploeg

> Alright, while I was thinking about the example, I think I finally managed to think this through better. > > > If we have named routes, then it is...

> Things that could be improved here are: > > * Like mentioned on the description, mention this on the docs > > * Maybe offer some helpers as that...

> Do we need it on `addAll` and `changeParent` too? The `addAll` uses a List we could add it there but eventually that would only be "single" type in that...

> I am failing to understand how adding a generics would to these methods would give more control or make it easier to enforce rules. Virtually adding the generics ``...

> By adding it to `addAll` too you would avoid a runtime error right? Maybe it even has to be added to add all... Otherwise the type checking wont succeed...

> That is not at all how I imagined that it would be used, since that would be a runtime error, and that runtime error can just as well be...

Weird idea, but can we not just do a `canvas.drawRect(Vector2.zero() & size, Paint()..color = backgroundColor())` (with some caching etc) at the start of our render pipeline? I mean even Flutter...

Might this not be a bit too soon? v1 just got released and we are focusing on not introducing any breaking changes unless really necessary or fully talked about it...

This is currently blocked by the fact that some of our bundles are currently in a private repository, once those are in their own public repos we can start working...

Side note: You can as a temporary fix override the `startDeeplinkObserver` in your Supabase state. ```dart /// Create AuthState. class AuthState extends SupabaseAuthState { @override void startDeeplinkObserver() { if (Platform.isAndroid...