ToolbarAndroid removed in 0.61

[thomasvm]

React Native 0.61 removed ToolbarAndroid from the provided components. This is not mentioned in the release docs and the component was not extracted into community package either. So there is no clear "path forward". Also, ToolbarAndroid is still mentioned as a provided components in the latest docs.

https://facebook.github.io/react-native/docs/toolbarandroid

React Native version: 0.61
System:
OS: Windows 10
CPU: (4) x64 Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
Memory: 3.51 GB / 15.88 GB
Binaries:
Node: 10.11.0 - C:\Program Files\nodejs\node.EXE
Yarn: 1.12.1 - ~\AppData\Roaming\npm\yarn.CMD
npm: 6.9.0 - C:\Program Files\nodejs\npm.CMD
IDEs:
Android Studio: Version 3.5.0.0 AI-191.8026.42.35.5791312

Steps To Reproduce

1. Upgrade project to react-native 0.61
2. Code that is using ToolbarAndroid fails with error message "Invariant Violation: Element type is invalid: expected a string (for built-in components) or a class/funcction"

[Smoothsmith]

I found the commit that removes it (Or at least, part of it):
31ab947#diff-39808e06333026f9ddb02287226012e1

But I don't know how to use that information to access/continue using it (Which our app does need to do - Hoping for a solution that doesn't involve rewriting parts of the app).

[thomasvm]

@Smoothsmith There is another commit that removes the Java part to FB internal
cbbbb45

What I ended up doing - and what I guess will be your best shot at the moment - is to include the JavaScript and Java code in our own codebase (with adjusted namespaces etc) and consume it from there.

[forki]

@hramos @cpojer Is there an official replacement? It's still in the docs and hit uns really hard.

[connectdotz]

hmmm... this seems like a major API breakage without any mention in changelog or blog, makes one wonder if this is an intentional change 🤔 ? We are already at 0.61.5 and there is still no official guidance on this issue... does the react-native core team not care about the tooling community or adoption of the new release? It would be great to have at least a discussion...

[Naturalclar]

@connectdotz I may be wrong, but I think removal of ToolbarAndroid has been discussed as part of a Lean Core, and I believe it was considered deprecated since RN 0.59

[forki]

@Naturalclar deprecation is not in the release notes.
and the toolbar is still in the docs. see https://facebook.github.io/react-native/docs/toolbarandroid

[connectdotz]

I stand corrected, @Naturalclar thanks for the link, it provided the missing context for me, but it only further deepened the puzzle of how ToolbarAndroid was removed...

After reading PR #24999, which enabled the removal of ToolbarAndroid, it became more clear how ToolbarAndroid could be replaced. But the migration is not clearly documented, to say the least... I understand this is just a "convenient" class and there is nothing special but a composite of core building blocks... However, the same thing can be said for many of the to-be-deprecated classes in the lean core initiative... again, I am not sure why ToolbarAndroid is being handled differently, i.e. it was removed without any clear documentation on migration path nor grace period for 3rd party libraries and user applications to adapt?

Will @cpojer and @ericlewis consider updating the document to clarify the migration approach? Better yet, maybe even bring back the ToolbarAndroid and deprecate it later with the rest of the lean core classes?

[ericlewis]

One could reimplement it as it’s own module based on what was removed.

This was quite a while ago. But if I recall the reasoning correctly, it was that it’s been long deprecated with the idea that more complete navigation solutions better implement this sort of thing. (And it’s easy to just copy paste in to your own project)

[connectdotz]

@ericlewis I completely agree that these kind of convenient components should live outside of react-native core, just that the removal approach for ToolbarAndroid is inconsistent with the rest of lean-core initiative components, not to mention the migration barrier it has imposed: first, you will get puzzling compile error, but nothing is mentioned in changelog, release note, and the official document didn't say anything should be different... well, you got the picture...

Furthermore, If ToolbarAndriod is a common component, I suspect it is, instead of everybody duplicates the code you proposed, it would probably be better to create an external package, as many of the lean-core components moving toward, no?