If its a single app for multiple platforms, and you are sharing code and views, why wouldnt you fit it in a single codebase? Surely to do otherwise would be unnecessarily complicated?
This is exactly what react native does. It uses native components (there is a cross-platform abstraction, or you can use the platform-specific components directly) and you implement the design guidelines in platform specific files: https://reactnative.dev/docs/platform-specific-code
> but not the views themselves
Without the views, why would it be in react native? React is for building the UI...
> Having one mega-app seems more of a complication to me.
single codebase != mega-app. There is no "mega-app" as the compiler only uses the code for the target platform. You can even target specific architectures and/or devices as it uses the native sdks behind the scenes.
Can you explain in more detail how you’d style a Heading element, block level image element, and a Quote element within the same editable TextInput? The important UX feature is that the user should be able to start a text selection in a Heading, and end the selection in the Quote, so when they press delete, the image is removed and the quote is merged into the heading.
1. Most useful resource for creating this feature would be official TextInput doc [1], no need for googling.
2. Unlike Web, it is possible to nest <Text> elements inside <TextInput>, which is what you need to use for styling your blocks.
3. So finally, you will need your Rich State, and you need a Parser function, which will translate this Rich State into a collection of <Text> elements representing your blocks.
There is a lot of nuance still, say, Image elements cant be nested directly into TextInput, so you need to generate a spacer Text block where you will host your image. Also it requires some bits of excellence to work out the selection and caret logic correctly, but overall – it's not that big of a task, I would do it in few days
- Native editor for IOS - Native editor for Android - Native editor for Web - Electron/Native desktop, etc...
These editor can share code via a clean architecture inspired state plugin hyerachy that's swappable (i.e, a shared provider that swap out state and data routing per platform). Then with metro or esbuild you can selectively prune the code branch. The UI can be done in RN-web if lazy or straight up native code. It doesn't matter at this level.
Then, anyone who wanted to clone Notion can consume this component in their RN app. However, this is against Notion interest atm afaik, since Notion must keeps its advantage (make it harder for people to clone Notion). I'd argue it will try to shutdown such an initiative until it found a better way to have an edge on these competitor (or maybe shift to a new market)
I don’t know how we could possibly shut this initiative down, but I guess I should try!
For us to build such a project without backing it with a webview would probably take an order of magnitude more engineers working on the editor than we have today.
I don't think Notion need to worry about FB. I think Notion might need to be worried about the potential market saturation caused by how easy it will be for a small team of 3 to clone Notion (and all of its integration, API, and so on) on all platform perfectly in a weekends. At that point, it's not the technology bottleneck anymore but more so a battle over branding and minor UX improvement.
My point is that users don't care if just showing a website in a WebView is misused technology. They want an app regardless and telling them "a website is a website" is futile.
And let’s not even think about those cases when a feature is written with not all the platforms in mind. I once had to fix a bug where a developer did not have access to an iOS simulator to test their pull request… so they had merged it in without support for iOS.
> developer did not have access to an iOS simulator to test their pull request
This is clearly a company's fault, just get him iPhone and Mac if he delivers mobile apps LOL
* and you really don't need much, unleast you need to implement a working WebRTC protocol from scratch, haha
Amazing stuff which React + Electron + React Native enabled - abstracting JS from Web to App - is so much crooked by folks trying to turn it inside out
React Native is not the future – for folks who don't understand how to use it. In fact they hate using it wrong. For me – it's the future, i can use only one language to create an Android, iOS, Windows, Linux and Mac native apps. (of course, i would never try to fit it into a single front-end codebase, this is pure madness)