as of react 3, adding extra functions to the config map just puts them under :fulcro$options key on both the instance and the class

whereas before you could actually decorate the class

what happens if you define a class with defsc then use gobj/extend to add a static method to it?

looks like that’s what defsc is doing internally anyway

https://github.com/fulcrologic/fulcro/blob/develop/src/main/com/fulcrologic/fulcro/components.cljc#L418

That’s exactly what I tried, but it didn’t appear to work. I’ll dig into it some more.

So gobj/extend was working, but the error was elsewhere. This library is a real pain to integrate with, but I’m 2/3 of the way there. I have wrappers that work for their AppContainer and Navigators, now just have to get a wrapper working for individual screens, which is a challenge because their Navigator appears to be swallowing all the props I try to pass in. 😤

You’ve read the book on the async function as a child pattern, right?

the whole with-parent-context stuff?

Yeah, several times. The problem is, it’s more like react-class as a child - it won’t let me pass in a function for individual screens. It wants the component class, and they are creating their own factory - so nowhere to intercept and sneak in props.

Ah, but according to the docs, it looks like the Navigator can take a screenProps in its props - that’s probably the fix. Trying now.

hm…yeah, another notch in the belt of “it would be nice if Fulcro components could act as standalone roots”

hm…though in this case I’m not sure how it would know the parent context…

Finally got it working! With a simple example, at least. Once I make it reusable and test it with my full app, I’ll add it to fulcro-native. This also paves the way for shared-element transitions, which build on top of react-navigation, so look for that feature next. 🙂