Fork me on GitHub
#fulcro
<
2018-12-01
>
tony.kay00:12:39

Ah, native…sorry, I don’t have much experience there unfortunately.

mdhaney00:12:29

I understand. What's really weird to me is how it works with Om.next, which is why I think it's something related to Fulcro. If I simply replace the Om.next calls with the fulcro.client.primitives versions (without even creating a full Fulcro client), same thing happens - everything works fine in dev mode with figwheel bridge, but breaks in prod.

mdhaney00:12:07

On a positive note, I was easily able to get a Fulcro server running as an Ion on Datomic Cloud. Would be happy to share that if anyone is interested.

currentoor01:12:15

i think there was someone in this channel that used fulcro with react native successfully, @tony.kay do you remember who?

tony.kay01:12:02

no…I know there were some others who played around with it, but don’t know if anyone tried release build

mdhaney02:12:08

I figured it out! As usual, it was a stupid little bug obscured by a jillion layers of tooling and complexity. But in a nutshell, the difference was that Om.next returns a regular fn from its factory method, and Fulcro returns a MetaFn. This factory ultimately gets passed to Expo when you register the root component, and of course JavaScript doesn’t know how to handle a MetaFn. Solution was easy - wrap the root component passed to Expo in an anonymous fn that then calls the underlying factory. I still have NO idea why it worked in dev mode - probably related to figwheel-bridge and how it loads things, which is still witchcraft to me. 😉

👍 1
wilkerlucio03:12:18

@mdhaney I have a demo repo with expo and fulcro here if you still need https://github.com/wilkerlucio/multi-timer

👍 2
tony.kay04:12:36

Ah, yes, that would be a difference. Fulcro needs to do that because of the changes to how dynamic queries work.