Use React Native instead of Bunsen-UI

[RangerMauve]

I love how Bunsen UI lets us basically have a web app that controls most of the browser features, but I worry that in the end it's still too limited.

The main problem with the current approach is that iFrames have limited functionality for stuff like indexedDB. This means that apps that rely on persistant storage (like fritter, or anything else that stores data somewhere) won't work with bunseon-ui wrapping the app in an iFrame.

I think that using react-native, and the postMessage / onMessage APIs that it provides for WebView components would be a better approach going forwards.

Getting node.js to run in ReactNative is pretty easy these days and you can still do most of the UI in JS (with React).

Plus, once this is working, it could easily be adapted to work on iOS.

One of the biggest problems with this right off the bat will be getting a storage backend for the files since IndexedDB isn't available in RN. This could be overcome by wrapping react-native-fs with similar logic to random-access-file and might end up being more efficient than indexedDB anyway.

The next problem will be the fact that you'll need to figure out updates to the app content. Having bunesn-ui means that it will all update automagically over dat. RN would require APK updates for changes to go through. This could eventually be solved by using a method for downloading the content locally. One could envision the app downloading the RN JS bundle from a dat to a local folder and making the app load from there if the download is successful.

Steps for the migration would be:

• [ ] Get a RN app which can spawn the gateway in a node process
• [ ] Build the UI for navigating to a URL
• [ ] Figure out the RN API for registering the app as a protocol handler for dat:// and auto-navigating to the URL on open.
• [ ] Wrap react-native-fs in random-access-storage
• [ ] Use random-access-network with the window.postMessage API in RN and some of the dat-polyfill code to have the DatArchive API persist data to the app storage
• [ ] Implement the methods required for addArchive (to persist to a list of archives) and the UI for selectArchive
• [ ] Test it out on iOS?

[rjcorwin]

So instead of the dat page being in an iframe, it would be at the top of the Android WebView. It wouldn't need to be React Native, really just any framework for a native app that manipulates an Android Webview, but I think the selling point of RN that you are pointing to is Android and iOS compatiblity, at least somewhat shared codebases.

What is the indexDb limitation that content in iframes have that you were referring to?

[RangerMauve]

IndexedDB is read-only when it's in an iframe. For some reason my phone won't let me paste the link.

[rjcorwin]

Ooooh man. If that's the case then I'm not sure what storage mechanism we've been using for a project at work where we fill out a lot of forms in an iframe and store them using PouchDB which I was assuming uses IndexDB in the backend.

[RangerMauve]

Weird. Maybe I'm wrong? I just found that from doing so.e searches. I think there was an issue that Chris ran into which needed the work I did with the polyfill that was resulting from this. I forget which issue it was in though.

[rjcorwin]

Maybe indexdb being read-only in an iframe is the case when it's cross domain? The project I'm referring to has the same domain for the parent and the child.

[RangerMauve]

Ugh, it sucks that there's no documentation on this behavior anywhere. :/ Maybe that's the case, then,. I wish I could find the issue that @chrisekelley posted his indexedDB problem in. 😅

[chrisekelley]

hey, i should check my github notifications more often!

Here's my recent activity in regards to indexdb/dat-polyfill/dat-gateway:

• https://github.com/bunsenbrowser/bunsen-ui/pull/8
• https://github.com/RangerMauve/dat-archive-web/issues/2

I think the first item is what you're talking about.

Finding a more flexible UI tooling makes sense at this point; we may have reached the edges of what we can do w/ iframes. react-native approach sounds like a strong candidate. This afternoon, RJ and I also chatted about using cordova's in-app-browser as another way to try to resolve this dilemma. I must admit I've worked w/ Cordova for a long time, and while I like to keep it as much html as possible, the Cordova plugin ecosystem can be a real pain. Plus we might have some big wins on the user experience going native.

[RangerMauve]

I used to do a lot of stuff in the Cordova space at work, but since switching to RN everything was a billion times easier and overall performance was a lot better (in production mode, it was way worse in development mode).

I guess Cordova would be a lot more appealing if you're not a fan of react. :P

Both projects support nodejs-mobile so it probably doesn't matter too much. Though, RJ messaged me earlier he managed to get it work by adding some sandbox-related flags to the iframe, so this might not be necessary after all.

With RN, it'd be easier to get a higher-performance and closer-to-the-fs random-access-storage implementation than an iframe or Cordova, however.

[RangerMauve]

Oh yeah, other advantage of using React-Native is we'll be able to inject JS into the webview. This will allow the dat-polyfill to be injected into all pages instead of having to do it at the gateway level or expecting pages to require the polyfill themselves

[RangerMauve]

I was thinking that we could ditch dat-gateway now that there's the discovery-swarm-stream-java thing.

You could have React-Native load up DatArchiveWeb (since it only really needs Websockets to work) and have it talk to the discovery-swarm-stream-java instance started in the background.

You can also easily inject a content script to enable the DatArchive API within the webview using the same process (but use dat-polyfill so that it does more URL rewriting stuff).

Instead of trying to set up Node.js, you could use react-native-http-server and make use of the DatArchive API to load the content to send the response.

[RangerMauve]

Oh, also it'd be safe to use a public discovery-swarm-stream instance since the operators would be unable to intercept any of your traffic.