Jake Wharton
Jake Wharton
A widget probably isn't going to be the best fit for a few reasons. The biggest problem is that all widgets need an associated view in the native view tree...
Although I'll note, showing a keyboard like that probably isn't useful or possible. To what input is it connected? Maybe only use the hiding half of that function and that's...
Everything dealing with coordinating the native UI should go into Redwood. It should then be exposed through Treehouse for when the composition moves to within the JS engine.
These secondary roots will get their own composition whose parent is the main composition. Need to figure out what this means for things like the Redwood protocol. Probably a monotonic...
I would not choose JSON since it diffs quite poorly. Simple plain text with indents (similar to metalava in AndroidX or the binary validator by Kotlin) or YAML/TOML diff well...
Ideas from meeting with Eric: * Reuse Android Lint which is a general-purpose Kotlin code linter and already has checks such as `NewApi` which handle conditional control flow gated on...
This also requires no version annotations directly in the schema. Instead for each version you update the schema manifest which adds all new widgets and the associated version but retains...
I'll also note this is in the Emoji sample. I replaced its root composable with a `Text` so I'm assuming this is the default behavior.
Let's unify both with #2275!
What part would you want to see benchmarked exactly?