Hi! I’ve been experimenting with and investigating multiple options for building a fullstack clojure/clojurescript app with RN as the main client app. Fulcro seems perfect for what I’m trying to build, and I’m really stoked about everything that’s been built out here and all the documentation. I am, however, planning on bypassing expo. Does anyone have any pointers on how to set that up with Fulcro?
@holyjak The RAD concept of schema on attributes is just a way to group the attributes together for some logical reason. From there the provided DB plugins use that to decide if the attribute belongs in their database. So, when the Datomic plugin generates resolvers and form handlers it only pays attn to attributes on the schema of interest.
So then then pathom db ENV plugin for the db adapters needs to know, for a given request, what connection to use with every schema that that database supports.
So, say you have a :prod
schema and you want to store that in SQL, and you have an :accounting
schema you want to store in Datomic. On the SQL side you decide to shard based on user, so some users go to db cluster A, and other users go to cluster B. You find that accounting data only needs a single database C. When a request comes in for some user that uses SQL A and accounting (C), you’d set the :prod connection to talk to A and the :accounting connection to C.
Etc.
It’s all really lightweight code (the plugins), so you can easily define it however you want, and invent whatever custom attribute options you desire to do it however you want.
I’ve got a project where RAD is integrated top to bottom and does many of the screens, and another where RAD is just doing a report or two and has no RAD back-end (just using plain Pathom resolvers).
@aleksander990 ummmm…let me see, I’ve got a bare RN app sitting around somewhere…
I think I followed the instructions for a bare react native app here: https://docs.expo.io/bare/exploring-bare-workflow/ But you don’t have to use the expo APIs (though I still find them convenient).
did the normal MainActivity stuff (return the name of the js module name)
nothing special in shadow, other than using the right target type
Unrelated to Fulcro: How much overhead does expo bare add vs react native CLI? (I was looking through the code here and trying to reverse engineer it for native native. https://github.com/fulcrologic/fulcro-native/blob/develop/src/main/com/fulcrologic/fulcro_native/bare.cljc). I’m a little worried about app size with expo, but from what I’m gathering it might not be too different than react native cli with bare
:app {:target :react-native
:init-fn app/init
you can choose what you add API-wise
I got all that setup. The build is compiling and working as expected. I’m just trying to figure out the render-root part
so I don’t think expo has to add anything
oh, ok, so…
(all the sample projects you’ve setup are immensely helpful)
I’m using `
:optimized-render! kr2/render!
keyframe render 2
:render-root! bare/render-root!
(from fulcro-native.bare)
then (app/mount! app root/Root :i-got-no-dom-node)
I think that’s it
what does this do? (i saw it but couldn’t quite figure out what it’s addding)
so you can plug in which algorithm is used to “refresh” after a transaction. This one normally renders from root, but supports you passing a targeted ident via transact!
to limit refresh to some specific component, which can be used to speed up large forms.
multi-root-render is just like KF2, but allows you to have disconnected nested data roots in the app.
ident-optimized-render tries to only update components whose data changes by analyzing the normalized database…but it turned out to be no faster in most cases, and is more complex to use.
don’t honestly remember what the default is right now 😜
ha ha, that’s fair. I’m thoroughly impressed with everything you’ve pioneered here. And your responsiveness on this. I appreciate knowing the “why”, so this makes me a lot more comfortable jumping in
Oh I see, I’m using expo’s registerRootComponent
in bare
I’d just look in the js and see what that does…it just adds a bit of expo magic in, but it stil lhas to call the RN low-level calls
import 'expo/build/Expo.fx';
import { AppRegistry } from 'react-native';
export default function registerRootComponent(component) {
AppRegistry.registerComponent('main', () => component);
}
doesn’t look like it does much at all 😜
so you should just be able to registerComponent yourself
ha ha, ok so I suppose that that, an asset management is the only thing that’s expo specific
yeah
yep, I’m the same way. Don’t like mysteries.
Out of curiosity: Do you remember the approximate app size of your RN apps? It looks like the base bundle is quite a bit bigger than the the reagent build I got running (1.2mb vs 5.2mb when building for release). My guess is that it’s because Fulcro includes a lot else, but my app right now is nothing more than a view with text in it
Ok, changing for this is all it took: (.registerComponent rn/AppRegistry “main” (fn [] Root))
Ok, a few notes: • I’d be happy to do a PR with a native.cljc for use cases without expo. It’s a simple change, but that’ll make it easy for anyone to get started • The alpha UI components imports a few components that have been moved outside core RN library (it throws a couple of warnings. So they should be removed • Preassigning all the basic ui-components seem to make them part of the bundle - regardless of whether you use them. (they won’t be treeshaken). I don’t know if that has to do with how (comp/isoget) is implemented or something else. Easy solution is to simply not do it and leave it up to the user. Meaning I’ll only do the import for the components I actually need. And then have the components ns expose the react-factory helper function Let me know if you have any thoughts on it. Otherwise I’ll experiment some more tomorrow and submit some PRs to the repo
(1) sure, adding a new ns for that is fine (2) Sounds like removing them is the right thing to do. (3) If you don’t require it, nothing should end up in your build. If it is required where not needed, I’m open to a fix.
I did a low quality test for number 3: I build a production build with them and one without them and it resulted in a 200kb difference. I can try to look through the actual index file and document in a PR
Thx, all! This was all so helpful today — I’ll post an update tomorrow. Feeling great, but I’ve got to turn in a little early, after a super late night last night. 🙂 I’m so grateful for all this help!
For a very specific use case, is it allowed to access a component's parent via this
(ie. (.-fulcro$parent (.-props this))
) ? Or is it definitely not part of the public API?
see comp/get-parent
the internal keys are unlikely to change names, but I make no guarantees about the internals of how components are implemented
@tony.kay Thanks, perfect. It seems to be a somewhat recent change as it was not part of the API version I was accessing on Cljdoc. Recent versions are faulty, namespaces don't show up. I tried rebuilding it but it fails.
This thread may be helpful: https://clojurians.slack.com/archives/C68M60S4F/p1607022810050300
I am working on getting latest Fulcro to Cljdoc
@holyjak Thanks, that would certainly be useful
Yeah. It was in F2, and I forgot to bring it forward until recently. Evidently not used much 😜