Trigger appear event after dismissModal (modalPresentationStyle -> overCurrentContext)

[lindesvard]

🚀 Feature

I want to be able to listen if a screen did appear even if the modalPresentationStyle is overCurrentContext. We have a quite large app with many independent teams and routes.

We need to keep track what the current displayed screen is. We do this by listening on componentDidAppear. Something like below

import { Navigation, ComponentDidAppearEvent } from 'react-native-navigation'

class NavigationStore {
  private currentComponentId = ''

  constructor(navigation: typeof Navigation) {
    navigation.events().registerComponentDidAppearListener(this.registerCurrentComponentId)
  }

  private registerCurrentComponentId({ componentId }: ComponentDidAppearEvent): void {
    this.currentComponentId = componentId
  }

  public get current(): string {
    return this.currentComponentId
  }
}

This works great until we show a modal with overCurrentContext. Below is a user journey where our problems occur.

push(A) // will trigger appear A
showModal(B) // will trigger appear B
dismissModal(B) // will trigger appear A
showModal(C, { modalPresentationStyle: 'overCurrentContext' }) // will trigger appear C
dismissModal(C) // will NOT trigger any appear event on A 

Not sure if this is a restriction on iOS but would love if we could get the appear event when a modal is closed with overCurrentContext.

• Have you read the Contributing Guidelines on issues?

Motivation

So have already talked about the motivation a bit but I can see this be quite useful for developers to know if a screen below a modal with overCurrentContext would re-appear after the modal is close. React to that, refetch data, track current componentId.

Pitch

Not sure if this would be supported under the hood (on iOS) but otherwise it could be implemented like this.

// pseudo code somewhere in dismissModal
await internal.dismissModal(componentId)

// does closed modal have overCurrentContext
if(options.modalPresentationStyle == 'overCurrentContext') {
  // basic check to find out what screen should trigger appear event
  if (!overlay.isEmpty()) {
    emitDidAppearEvent(overlay.getLast())
  } else if (!modal.isEmpty()) {
    emitDidAppearEvent(modal.getLast())
  } else {
    emitDidAppearEvent(stack.getLast())
  }
}

Are you willing to resolve this issue by submitting a Pull Request?

• ✖️   Yes, I have the time, and I know how to start.
• ✅   Yes, I have the time, but I don't know how to start. I would need guidance.
• ✅   No, I don’t have the time and I’m okay to wait for the community / maintainers to resolve this issue.

[swabbass]

Well, that is the essence of overCurrentContext, which means that the context on which the modal is being shown upon is still "visible" (appearing) to the user, hence, the context, here is the bottom modal, did not receive didDisappear event when modal on top is shown, which in turn no didAppear should be sent.

So the premise overCurrentContext relies upon, the fact that the shown modal (top) hosted over the context (partially or fully) without it being gone, which means the "context" (bottom) did not disappear.

Now, didAppear event is sent in 2 cases:

1. Initially when the view was not there and it becomes visible.
2. The view was "disappeared" for a reason like pop or push in the case of a stack for example (showModal with default modalPresentationStyle which behaves like a stack of modals).

In both cases, the disappear event was sent because the view is gone, hence, not visible to the user, and in the case of overCurrentContext the "context", which is a modal in your example is not gone.

So what you are suggesting is defying the logic behind overCurrentContext, but, I can suggest 2 solutions:

1. Use default presentation style and set layout background to be transparent somehow and see if that fits your needs.
2. Introduce a new event about a view becoming interactable, which covers your case, which means you might need to open a new feature for such an event.

[swabbass]

Converted to a discussion under ideas.

[lindesvard]

Yes, so I get your point regarding overCurrentContext that the screen behind actually is visible. I would prefer fullscreen since we actually get the did appear event when closed, but we cannot set the background to be transparent for that (tried transparent, null, #FFFFFF00, rgba(0,0,0,0)).

So the left image we do get did appear but unable to set background transparent. The middle is what we want but none did appear when closed. Right does not give any did appear event either.

So ideally the best thing would be to just support transparent background for fullScreen or currentContext. Because for these presentations we actually get the didAppear event after closing. Not sure if this is possible on the native side tho.

Your proposal with interactable event might be something if above is not possible.

[lindesvard]

Another solution would just be to expose a method that gets the current componentId. Then I can just do something like this.

Navigation.events().registerCommandCompletedListener(() => {
  const componentId = Navigation.getCurrentComponentIdSync() 
  console.log('Currently active screen is', componentId)
})

edit: Might just do this for registerModalDismissedListener and componentDidAppear so its not called unnecessary

[swabbass]

Well, we need to check couple of solutions starting from most elegant to less ones as follows:

• Supporting transparent background, but seems to me it is can have issues on ios because on android it would work I think.
• Add an option forceNormalLifecycle which causes the overCurrentContext to behave like default.
• Add new componentResumed and componentPaused for such cases.
• Add getCurrentComponentIdSync which might help a bit, with flags to bypass overlays (edge case).

So it all starts on ModalPresenter.java#onShowModalEnd where we call to detach the view that is being removed as part of showing new modal and in the case of overCurrentContext no detaches will happen, so we need to inspect all of the above solutions and make a rational change so the lifecycle would make sense logically and a change that a normal dev can expect how a component would behave.

[lindesvard]

Supporting transparent background, but seems to me it is can have issues on ios because on android it would work I think.

Seems like this will not be possible what I have read. Then we need to use overCurrentContext.

That leads me to the second option

Add an option forceNormalLifecycle which causes the overCurrentContext to behave like default.

I assume you mean that with this path we would add custom logic to handle appear for iOS if overCurrentContext and forceNormalLifecycle is set? As you said, seems like a simple fix for android but not sure how much work this would be on iOS.

Add getCurrentComponentIdSync which might help a bit, with flags to bypass overlays (edge case).

Don't quite agree this is the least elegant solution. Might be for this use-case but feels like a good method to have in a navigation api?

[swabbass]

I sorted them just in terms of "The number of lines of code devs need to write to achieve the wanted behaviour", flag vs new event vs new API, I may get some stuff wrong :] , for that we have discussions.

Since I have little knowledge of iOS, @yogevbd, wdyt about this discussion? how can we achieve the wanted behaviour?

for now, I think the remaining options are:

• getCurrentComponentIdSync
• new Event to be called when a component is the main "focus" or some sort of onResume/onPause similar to android, or you name it, I'm bad with naming stuff.

[lindesvard]

Hehe ok! Both of these changes would be much welcome.

For the event I would go with componentDidFocus & registerComponentDidFocusListener.

getCurrentComponentIdSync feels like a good thing to have for other use cases. Since we already have (I assume) all needed information on the native side for doing this. Then it would just be a matter of exporting this to the bridge.

[yogevbd]

@lindesvard This is how it works on iOS, you should consider the option that multiple screens can appear at the same time.
I suggest managing it in an array, add the component on appear event to the array and remove it on disappear, then you will always have the top appeared component in the array.

[lindesvard]

So I have played around a bit and this is the best approach I have found. Have removed quite a lot of business logic we have on our side but this might help others that struggles with the same problem.

Basically we do as follow. Always listen to the ComponentDidAppear. If the current route has overCurrentContext we add it to an array state.bottomSheet. For routes that is not a bottomSheet we just keep it as a string.

If a modal is closed we listen to ModalDismissed. We check if the screen that was dismissed is a bottomSheet, if so we remove that from the state.bottomSheet. After that we get the currentComponentId and emits an event.

So now we can listen on emitter.addEventListenr('focus', ({ appeared, disappeared }) => {...}). But we can also do getCurrentComponentId in epics or actions outside react components.

Interesting note. If I have several modals (overCurrentContext) opened and close a modal that is already behind another one DidDisappear is not called. That's why I listen on registerModalDismissedListener instead.

Sorry for wall of text!

import EventEmitter from "events"
import { Navigation, CommandName } from "react-native-navigation"

const state = {
  other: '',
  bottomSheet: [],
}

function getRoute(componentId: string) {
  // Logic we have to get a route definition
  // routes = { key: { component, presentation, ... } }
}

export function getCurrentComponentId() {
  return state.bottomSheet.length ? state.bottomSheet.length[state.bottomSheet.length - 1] : state.other
}

export const emitter = new EventEmitter()

Navigation.events().registerCommandListener((command)=> {
  // Clear bottomSheet stack if SetRoot or DismissAllModals is called
  if(command === CommandName.SetRoot || command === CommandName.DismissAllModals) {
    state.bottomSheet = []
  }
})

Navigation.events().registerModalDismissedListener(({ componentId }) => {
  // Get route by componentId
  const route = getRoute(componentId)

  // Only handle cases when the current modal is `bottomSheet`. 
  // For other modals we get `componentDidAppear` event when closed 
  // and can decide current screen
  if (route?.presentation === 'bottomSheet') {
    // Remove dismissed modal from state 
    state.bottomSheet = state.bottomSheet.filter((cId) => cId !== componentId)
    
    // Get current route
    const current = getCurrentComponentId()

    // emit
    emitter.emit('focus', { appeared: current, disappeared: componentId })
  }
})

Navigation.events().registerComponentDidAppearListener(({ componentId }) => {
  // Get route by componentId
  const route = getRoute(componentId)
  // Get current route which will be emitted as previous
  const prev = getCurrentComponentId()

  // Check if current route has presentation `bottomSheet` (overCurrentContext)
  if (route?.presentation === 'bottomSheet') {
    state.bottomSheet.push(componentId)
  } else {
    state.other = componentId
  }

  // emit
  emitter.emit('focus', { appeared: componentId, disappeared: prev })
})