Maintainer wanted

[ohanhi]

I am looking for an interested maintainer for this project.

There are many factors related to this, but here are some:

• My initial goal of seeing if Elm on React Native was possible has been proven to work a long time ago. However, in my opinion React Native as a platform does not really conform to the Elm ideals: things keep breaking all the time.
• I haven't been using the technology myself, which is why I've mostly been merging pull requests and not developing features.
• I no longer have an Apple computer, so I cannot (easily) develop things that are related to iOS.
• Approaches like the one explored as a Google Summer of Code project (https://github.com/pzp1997/elm-ios), going beneath the React Native layer, seem like a much more compelling way to do things like this to me personally. Evan Czaplicki also very much agrees.

What I will still contribute to this project is #89. I will make a proper write-up of all the thinking and evaluating that has happened sort of behind the scenes thus far. Hopefully that will also shed some more light into why I no longer wish to actively maintain the project.

[ohanhi]

As a first thought: @jsteiner, you've been more active than I have during the past year or so. Would you be interested in this?

[jsteiner]

@ohanhi thanks for offering, but I'm no longer working on any projects with this.

@iancanderson has contributed in the past, and while I don't think he is interested in being a full on maintainer, I do think he has interest in contributor access.

[iancanderson]

Indeed, I would love contributor access if possible. I do think you're right that this project probably won't be the best way to write elm apps on mobile, but it's currently the only "real way" to do so at the moment, so I'll be using it in the short term future.

With contributor access, I'd be willing to give feedback on PRs/issues when I can. I work on a Mac, and work on Purple Train every once in a while, so I can offer some real-world experience.

[ohanhi]

All righty, I sent you an invite.

[iancanderson]

Thanks @ohanhi!

[jatinderjit]

@ohanhi We've been using your ideas to develop our company's internal system, which powers both web and native app with the same code base (with a few case statements thrown here and there).
@saleemjaffer and I would like to help with the project. We currently don't have the bandwidth to engage actively, but we can try to start working on some features you might have in your pipeline, and see how it goes.

And thanks btw for the project :)

[ohanhi]

@jatinderjit Great! Feel free to work on any features and make PRs. :)

[renatomassaro]

Hey all! I'm a bit late to the party but would like to help.

We are building an MMORTS with location-based gameplay. We use Elm for our frontend (Browser / Electron), and plan to use elm-native-ui for our mobile UI. I'd like to help move this project forward (though I probably cannot afford to be a maintainer).

Is there a proper forum / chat we can further discuss elm-ios, which you mention might be a better approach than using React Native? (I, too, agree, but feel we might miss on the "cross-platform" side of RN).

Finally, thanks @ohanhi for such amazing project 😃

[akavel]

Having a version of ENU ported to RN 0.55, and inspired by a quote from a recent post by React Native engineers:

When we started the React Native project in 2013, we designed it to have a single “bridge” between JavaScript and native that is asynchronous, serializable, and batched. Just as React DOM turns React state updates into imperative, mutative calls to DOM APIs like document.createElement(attrs) and .appendChild(), React Native was designed to return a single JSON message that lists mutations to perform, like [["createView", attrs], ["manageChildren", ...]]. We designed the entire system to never rely on getting a synchronous response back and to ensure everything in that list could be fully serialized to JSON and back.

I dug deeper into RN, and managed to find what seems to be the underlying message bus mechanism for passing pure JSON messages between Java/Swift and JS. The low level interface for this on the JS side seems to be implemented in the MessageQueue class, specifically methods named enqueueNativeCall (JS->native) and callFunctionReturnFlushedQueue+invokeCallbackAndReturnFlushedQueue (native -> JS):

+-------+  MessageQueue                           +--------+
|       |   .callFunctionReturnFlushedQueue /     |        |
| Java  |   .invokeCallbackAndReturnFlushedQueue  |  JS    |
|   /   +------------------------------------------>       |
| Swift |                                         | (Elm?) |
|      <------------------------------------------+        |
|       |         MessageQueue.enqueueNativeCall  |        |
|       |                                         |        |
+-------+                                         +--------+

Reportedly, messages passed through this queue look more or less like below:

{type: 1, module: "WebSocketModule", method: "addListener", args: Array(1)}
{type: 1, module: "WebSocketModule", method: "connect", args: Array(4)}
{type: 0, module: "RCTDeviceEventEmitter", method: "emit", args: Array(2)}
{type: 1, module: "Timing", method: "createTimer", args: Array(4)}

where type is direction: 1 = JS->native, 0 = native->JS.

I'm hoping this could enable hijacking the message queue on JS side for Elm, and thus building a similar construct as the one prototyped in pzp1997/elm-ios (where applyPatches does Elm->Swift, and handleEvent does Swift->Elm), bypassing (almost) all of JS RN code. Hopefully, it should still make it possible to reuse Expo and other relevant RN deployment infrastructure. (If not forever, then at least as an intermediate stepping stone and exploration before maybe rewriting Expo to some custom-tailored solution for Elm at some point in future.)

I want to try and explore this direction further. However, I'm not sure if I'll have enough "juice". I may as well silently fail or get distracted. Because of that, I wanted to put down my findings here, to advance the common case, and in case someone else would also be interested and want to follow up with their own explorations in this area.

Cheers!