search

jordwalke / native-reason-react-roadmap

Public design discussion about various approaches to building Native Reason React.
24 stars 1 forks source link

Our idea for React Native bindings #4

Open grabbou opened 6 years ago

grabbou commented 6 years ago

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.

jordwalke commented 6 years ago

Sorry for the delay in answering. I've been pretty heads down working on a tool that autogenerates Reason->JS Flow bindings from pure Reason libraries, which sounds like it overlaps with your general direction.

I think a lot of your ideas here are about tailoring the high level CLI workflows for a "Really Native Reason React". I think for a Really Native Reason React, we can reimagine the total workflow. At least that's how I've been thinking about it. A lot of the tooling is very JS centric and I'm sure if we started with a statically typed (native capable) language we'd end up with different workflows. For example, we don't need a bundler for JS at all. We only need a cross platform bundler for general assets. Maybe that's what you were getting at.

A couple questions:

What is react-native link? I haven't used it

ulrikstrid commented 6 years ago

Is the plan to reuse react still or do you want to do a implementation of that as well? Have you had a look at either Brisk or Pure? Could either of those be used as a starting point?

jordwalke commented 6 years ago

Reimplementing React is a requirement of Really Native React Native. We can still use all the bindings to native view managers - we just need to speak the right protocol over the RN bridge. But sitting on the (previously) JS side of the bridge would be native Reason, and that would require reimplementing React in Reason. I'm sure a lot of people would have fun reimplementing React in Reason, and we can all compare/share implementations of that. The majority of the work is in integrating with RN's bridge protocol. To avoid the cross-compilation challenges so early, you could start with desktop native, and play off of some of the RN-for-desktop work (proton).

grabbou commented 6 years ago

That's where we are headed. Had a quick chat with @jordwalke few weeks ago to go over this issue a bit more in details. Right now, we have postponed our work around v2 (which aims to go with fully native Reason code to talk over the bridge) while we observe pending breaking changes happening to native part of React Native (aka Fabric).