devTools prop about rfcs

[satya164]

I think people might want to track actions for other reasons than devTools

Actually the reason I talked to @Ashoat about a devtools specific API is because I don't want people to be tracking actions other than for debugging purposes. It can cause subtle issues and coupling when people start to track actions imo.

For example:

• Action names don't matter, a reset action could do the same thing as a navigate or a push, what matters is what changed, not the action that caused the change.
• If people start relying on actions, it makes it impossible to change our navigator code. For example, if we changed goBack() to pop(), it will break user code if someone is relying on listening to it to detect going back.
• Since navigation configuration is dynamic, other things can cause the state to change (such as user's component state), it's not always 1-1 for action -> state. People relying on actions to detect changes will subtle bugs.

Instead, people should rely on checking what changed in the state, e.g. - the focused screen changed, so change statusbar style or something. I think this also works like React works, run an effect based on what changed, not how it changed.

onAction would be very useful, I was actually trying to implement preloading requests with relay (starting the request as soon as the navigation action is dispatched instead of waiting for the screen to render) but it was pretty hard and required a custom router.

Isn't action -> screen rendering almost instant? At least for network requests, a few milliseconds doesn't seem like it would be noticeable.

Anyway, the use case seems to be to get notified before screen render, not necessarily get notified of actions. An action might not even change anything. With suspense, I assume we'd need some sort of API for preloading anyway, so it's something we'd need to think about.

Another case to know before state change is to be able to prevent a state change, e.g. prevent going back from the screen (e.g. if user is editing something), but it also doesn't need to be an action listener (rather can't be, goBack and pop should both work for this for example).

For this use case, there would need to be some API that'd need to notify with upcoming state before it's applied, with ability to prevent it, or some more specific APIs for specific purposes.

If separate devtools API isn't something we want, to avoid duplication, another option is to expose something like containerRef.addListener('__UNSAFE__action', callback) to emphasize that this is unsafe.

Then the devtools stuff can be implemented in a hook and used like:

useReduxDevToolsExtension(containerRef)

The container's ref has other methods like getRootState, resetRoot, dispatch etc. for the devtools to interact with the navigator's state.

[ericvicenti]

Hey Ashoat! I really like the idea of cleaning up useDevTools to use a public API rather than the internally-hardcoded global.__REDUX_DEVTOOLS_EXTENSION__.

Good point that state changes do not map 1-1 to actions. But, I think people might want to track actions for other reasons than devTools, so maybe we should just add an onAction prop to the container?

My other concern is that devTools.trackStateChange seems very similar to the existing onStateChange prop.

We could possibly provide a default behavior to onStateChange and onAction which calls out to the redux devtools. There are other ways to sugar-coat this, including the devTools prop you described.

I think you're on the right track, I just hope to keep the container props as simple as possible.

[Ashoat]

That makes sense. I'm curious to hear @satya164's thoughts, as he initially suggested explicitly mentioning "dev tools" in the naming to avoid any confusion.

I'm pretty flexible on the API, mostly just want a way for users of the library to track actions.

[janicduplessis]

onAction would be very useful, I was actually trying to implement preloading requests with relay (starting the request as soon as the navigation action is dispatched instead of waiting for the screen to render) but it was pretty hard and required a custom router.

[Ashoat]

Closing now that @satya164 has implemented this in @react-navigation/devtools!