Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal to detach children before self #612

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -206,11 +206,11 @@ protected constructor(
public open fun dispatchDetach() {
checkForMainThread()

interactorGeneric.dispatchDetach()
willDetach()
Copy link
Contributor

@psteiger psteiger Sep 22, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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()

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

for (child in children) {
detachChild(child)
}
interactorGeneric.dispatchDetach()
}

/**
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -97,16 +97,23 @@ class InteractorAndRouterTest {
router.dispatchDetach()

// Then.
val ribActionInfoValues = ribActionInfoObserver.values()
ribActionInfoValues
.last()
.assertRibActionInfo(
RibEventType.DETACHED,
RibActionEmitterType.ROUTER,
RibActionState.COMPLETED,
"com.uber.rib.core.FakeRouter",
)
verify(childInteractor).dispatchDetach()
val ribActionInfoValues = ribActionInfoObserver.values()
val childRouterDetachIndex =
ribActionInfoValues.indexOfFirst {
it.ribEventType == RibEventType.DETACHED &&
it.ribActionEmitterType == RibActionEmitterType.ROUTER &&
it.ribActionState == RibActionState.COMPLETED
}
val selfInteractorDetachIndex =
ribActionInfoValues.indexOfFirst {
it.ribEventType == RibEventType.DETACHED &&
it.ribActionEmitterType == RibActionEmitterType.INTERACTOR &&
it.ribActionState == RibActionState.COMPLETED
}
assertThat(selfInteractorDetachIndex).isGreaterThan(-1)
assertThat(childRouterDetachIndex).isGreaterThan(-1)
assertThat(selfInteractorDetachIndex > childRouterDetachIndex).isTrue()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we are detaching child before parent now, the router detach is no longer the final event.

}

@Test
Expand Down
Loading