I'm not sure this is actually a practical idea, but I spent some time looking into making main work this week, inspired by this discussion linked to from the readme.
The elm compiler enforces that the return type of main be either Element, VirtualDom.Node (aka Html) or a signal of either of the above.
In theory you could overwrite the Native.VirtualDom.node function and replace it with whatever you want, or you could define a new function that claims to return a VirtualDom.Node but actually calls out to Native.ReactNative.node (or something).
But I'm not sure that it's actually necessary to replace the VirtualDom node type at all. virtual-dom nodes are already similar enough to the VTree in this project that you could probably just use them directly.
Replacing the render and updateAndReplace functions from the virtual-dom package would probably look very similar to the vtreeToReactElement function you've already defined.
One thing I discovered when poking at this is that, out of the box, React Native will blow up if you include the virtual-dom package. This is because the elm virtual-dom wrapper is built with browserify, which defines a function named require. This confuses the RN packager, which will try to use its own require function instead. If you globally replace require with e.g. _require in the compiled elm.js, it will load fine.
Anyway, I'm hoping to have more time to muck about with this soon, but I'm curious to see what you think. Nice work so far, btw :)
ohanhi
commented
8 years ago
I'm not sure this is actually a practical idea, but I spent some time looking into making
mainwork this week, inspired by this discussion linked to from the readme.The elm compiler enforces that the return type of
mainbe eitherElement,VirtualDom.Node(akaHtml) or a signal of either of the above.In theory you could overwrite the
Native.VirtualDom.nodefunction and replace it with whatever you want, or you could define a new function that claims to return aVirtualDom.Nodebut actually calls out toNative.ReactNative.node(or something).But I'm not sure that it's actually necessary to replace the VirtualDom node type at all.
virtual-domnodes are already similar enough to theVTreein this project that you could probably just use them directly.Replacing the
renderandupdateAndReplacefunctions from the virtual-dom package would probably look very similar to thevtreeToReactElementfunction you've already defined.One thing I discovered when poking at this is that, out of the box, React Native will blow up if you include the
virtual-dompackage. This is because the elm virtual-dom wrapper is built with browserify, which defines a function namedrequire. This confuses the RN packager, which will try to use its ownrequirefunction instead. If you globally replacerequirewith e.g._requirein the compiledelm.js, it will load fine.Anyway, I'm hoping to have more time to muck about with this soon, but I'm curious to see what you think. Nice work so far, btw :)