proposal to detach children before self #612
Conversation
|
Has this been verified in the Uber monorepo? Tests passed and apps worked? |
No, not yet - was creating this pull request to collect information on whether to do this at all (and if yes, gather information on what would be considered a sufficient test) |
|
Suggest a first pass with a custom built dependency to understand the scope of the migration |
|
Update: After smoke testing with Uber's big apps, decided to limit the change to only move the "detach self" ahead of "detach children" and leave the "will detach" position untouched |
davissuber
force-pushed
the
ds-swap-detach
branch
from
128972e
to
9bc16f2
Compare
| } | ||
| assertThat(selfInteractorDetachIndex).isGreaterThan(-1) | ||
| assertThat(childRouterDetachIndex).isGreaterThan(-1) | ||
| assertThat(selfInteractorDetachIndex > childRouterDetachIndex).isTrue() |
There was a problem hiding this comment.
Since we are detaching child before parent now, the router detach is no longer the final event.
| @@ -206,11 +206,11 @@ protected constructor( | |||
| public open fun dispatchDetach() { | |||
| checkForMainThread() | |||
|
|
|||
| interactorGeneric.dispatchDetach() | |||
| willDetach() | |||
There was a problem hiding this comment.
Should the router willDetach come after interactor detach? IMO this should be the last line. What issues did you encounter with this (if any)?
I'm thinking of:
for (child in children) {
detachChild(child)
}
interactorGeneric.dispatchDetach()
willDetach()
There was a problem hiding this comment.
What I had noticed was that some existing RIBs in Uber's app are overriding the willDetach() (and sometimes even call detachChild() themselves e.g. BikeHomeRouter) and/or do other sorts of clean up stuff that needs to happen before detachChild() is called by Router.
I think those seemingly ani-pattern-ish usage may be symptoms of the fact that we are detaching parent before child.
There was a problem hiding this comment.
I think you are right.
I've been thinking about this, there's nothing super wrong with calling willDetach before everything else. It can be understood as a signal that router X is starting its detach process, which now will begin with detaching children (instead with detaching self). That makes sense.
This pull request stems from #589 and attempt to swap the detachment order between self and any attached children to avoid a small window in which the child is active and parent is not.
Note that this only updates the Android part - the corresponding iOS behavior remains "detach self before children" even after this pull request.