Sebastian Sellmair

I think this might be another symptom of #2 (where native stdlib might be not wired up correctly in this case). I will post an update here once I am...

Sure! Right now, if a fragment asks for its corresponding `route` object, its arguments will get deserialized and returned by the `ParcelableFragmentRouteStorageSyntax`. It *might* be a good idea to go...

> In addition to this, the storage would be bound to an ActivityLifecycleCallbacks and a FragmentLifecycleCallbacks on the Application, and whenever a Fragment with an ID bound to an existing...

@isaac-udy Let's go for it! We can make it configurable which implementation the router will use under the hood 👌 Maybe defaulting to the `direct` storage would make sense!

I think you raised a few very interesting points here! > Multiple paths to one goal: 1. ``` router.clear() router.push(Route()) ``` Exactly, this will work but won't bundle those instructions...

> What would you think if we made route { } execute as a single stack instruction, and use it as an "instruction chain builder" as Zhuinden suggests? You mean...

Or would you propose that the following syntax: ``` router { clear() push(route1) push(route2) } ```

Haha I get it 👍 I even had a draft supporting this kind of syntax at the beginning. The problem with it is, that it kind of doesn't fit into...

Exactly! That was also what I had in mind, but I am not quite sure about it. Maybe one of my colleagues can contribute its thoughts on this tomorrow. I...

Another idea: What about having something like: `router.clear().push(route1).commit()` Whoever wants to do custom routing with the `List.() -> List` can still open the lambda like `router { clear().push(route1) }`? What...