jordwalke / native-reason-react-roadmap

Public design discussion about various approaches to building Native Reason React.

native-reason-react-roadmap

Public design discussion about various approaches to building Native Reason React.

Don't be shy with the Pull Requests or "New Issue" button.

Overview of Goals And Approaches

We will fill this in with high level overview of various approaches and goals as we come to consensus.

Projects:

Here is where we'll link to existing efforts and experiments to learn from or contribute to.

Discuss:

Use Github search to see if a topic has been discussed, and if not open a new issue. Pretty much anything is fair game: questions, comments, ideas, concerns.

If you have an interesting finding or idea to share, create a PR with a .md file describing the idea/finding (put it under a directory with the same name as your Github user name). We'll keep the main README.md as a place to summarize all of the discussions as we come to a consensus about what the best goals would be.

native-reason-react-roadmap's Issues

Document Reprocessing Apps:

I've been interested in the cross compilation and package management aspects of a Really Native React, because I see it being one of those things that you end up needing to solve and it takes a long time to solve - so you better get started early! Furthermore, the React component model encourages sharing of code, and when you start sharing code, you need a way to consume that shared code.

But let's also carve out some space here to discuss (and link to) some more constrained workflows that don't have as much to do with React Native, and might have a more narrow focus: For example, a lot of the findings from Reprocessing apps will be useful here and there's probably some work we could share. @bsansouci I'm sure you could fill an entire directory of markdown files sharing your findings and approaches so far! Are you inclined to author some guides? (For example, I think your bundling of mingw-gcc was very cool - it would be good to get the story of how you did that in markdown form). If not, that's totally fine too.

Our idea for React Native bindings

Hello everyone,

First of all, thanks for kickstarting this and consolidating our efforts so that we all can share our experience, efforts and work on new, exciting ways of running apps cross-platform! I am pretty sure that some of you might be already familiar with our approach as @knowbody talk to few of you at ReasonML Conf (that I couldn't attend, unfortunately). Anyway, reposting here for reference and to kickstart discussion before we accelerate our official efforts.

After writing and publishing our navigation library (callstack/reroute) and discovering the benefits of writing dedicated libraries in Reason based on existing Javascript ones rather than writing bindings, we came to the conclusion that doing the same for React Native could carry a lot of benefits.

That said, our initial goal was to create a minimal framework based on React Native that provides a whole new frontend to its existing native code (all Javascript gets reimplemented). I would see that as a minimal and modular alternative that would build on React Native foundations. Created from scratch as a separate product, it wouldn't be backward compatible with React Native.

The first thing that comes to my mind is the opportunity to decouple React Native from Metro and make the infrastructure support any bundler user wants. The other one is to get rid of the local-cli (command line tools) that keep growing and provide a minimal, yet a friendly interface for deploying apps. Another one, that I think is as important, is the user experience. For a while, there's been an issue to provide a native-less way of writing React Native apps, that is, by using .native folder and providing commands to do the work behind the scenes for the user. We've been doing some preliminary work in those areas (with products such as react-native link) but never managed to connect them all together.

I am curious to hear what you think and whether there have been any discussions about such approach in the past. I know the plan is ambitious and involves a lot of work, but we at Callstack are dedicated to developing cross-platform products and if there's any way to improve on existing libraries, we are keen to try it out at any cost.

Ideas for decoupling work

We can have the main README.md be an organized summary of end goals and tasks/dependencies between them. I'll use Issues as a way to brainstorm / discuss.

I had one idea about a way to decouple cross compilation tooling from actually building all the necessary abstractions and utilities. A long time ago, I had insisted that the React Native bridge be serializable. That doesn't mean that we had to serialize in practice, but just that the bridge API could be implemented in a serializable manner. The reason I originally insisted on that is that it made tooling so much easier (given infinite resources, making it easier to build tooling wouldn't matter).

For example, you could run your React JavaScript App running in a Chrome instance, making use of its debugger, but send messages across the network to your actual device, or simulator. This could also easily be done over the air so you didn't even need to plug a device in. So that's just one example of how a serializable bridge was immediately useful.

A serializable RN bridge is also beneficial for moving Really Native React forward because it can help us decouple longer term projects like cross compiling packages, from smaller and isolated ones like: "building out a message queue to communicate with iOS/Android".

For example, you could build everything you need without solving cross compilation, by building out everything but cross compilation support, and running the code on your laptop's OS/architecture, while serializing the commands over to the device - and you'd see your code rendering real native views on device, with your code running natively - on your laptop, remotely.

Dream Package Manager Workflow:

My dream workflow for building native apps would look something like this:

git clone myApp.git
cd myApp
esy install
esy build --target=armv7 --platform=ios-sdk
esy build --target=armv7 --platform=android-sdk

To add a dependency, you'd be able to simply add any opam package (or package hosted on npm) to package.json, and then rerun esy install && esy build --target...

• The dependencies don't need to anticipate being cross compiled in the majority of cases.
• The ones that do need to do something special in the cross compilation case, would use some convention for ocamlfind toolchain names and we'd provide the right hooks for that, but 90% of packages shouldn't need to worry about it (unless they define their own ppx plugins perhaps).

Forking:
You shouldn't need to fork packages in the common case. If we do in some cases, then we can possibly use a "resolutions" style field to consume those forks.

This is just an idea for the "dream workflow". In practice, we might need to compromise.

cc @rauanmayemir / @andreypopp

There's a lot to discuss about cross compilation, but let's keep this thread limited to the things that apply to Really Native React, or mobile.