Fork me on GitHub
#fulcro
<
2019-12-27
>
tony.kay07:12:38

@mroerni not sure what you’re asking…render the child? It’s no different in a card than it is in any other root

Björn Ebbinghaus07:12:43

I think my question was bad.. To create a fulcro-card you provide the component class and do not use the factory like usual. Because of that you have to use the ::ct.fulcro/computed key for computed props. There is nothing like that for children I guess? I first thought I may achieve that by writing: {::ct.fulcro/wrap-root? false, ::ct.fulcro/root-node-props {:children [child1 child2]} but that doesn't seem to work.

tony.kay19:12:32

Remember that the fulcro card is simulating an entire app. If you want to render a component using factories without the app, then you can just use a normal react card. If you want an, app, use the fulcro card, and you can use the app key, I think, to pass in startup options, use initial state, etc.

tony.kay19:12:36

If you turn off wrap-root, then you’re completely in control of what children your own root has…there is no way around the fact that a fulcro card is an app, and must follow all the rules for a root for an app.

tony.kay19:12:57

So, you have to write a custom root for your app if you have special construction needs

Björn Ebbinghaus14:12:00

Hm. I see.. I have a component that is like a sortable list. So it has its own ui only state. It just needs some children for it to render something. I guess it is not important enough to worry while on vacation.

currentoor19:12:55

this is useful to know, thank you

👍 1
tony.kay19:12:56

Also, just FYI, Fulcro itself does not require the metadata support. I believe he is using the metadata for something additional particular to his app.

🎉 1
codonnell19:12:44

I'm not using it at all, actually. But that namespace fails to compile with the older transit-clj dependency since the write-meta function doesn't exist. I'm currently trying to use a locally patched version that removes the call to write-meta as suggested in the linked thread.

☝️ 1
tony.kay19:12:11

oh…I forgot that got added…

tony.kay19:12:02

Ah, right…dynamic queries use metadata in app state, and that is needed if you’re using SSR…I was wrong about Fulcro not using it…it does, but JUST for SSR state encoding. We could probably move that elsewhere to prevent problems.

tony.kay19:12:31

We can open an issue for that @codonnell…but it would be technically a breaking change, since we would at least have to move those functions.

tony.kay19:12:19

one thing you could do is monkey patch the datomic ns and add that function into the transit ns in clj

codonnell19:12:27

I'm not planning on doing SSR for this project; up to you if you think that breaking change is worth making to ease usage via datomic ions. Worth noting that @foo mentioned some conflict with clojurescript, as well. I don't know the details of that.

tony.kay19:12:07

yeah, I know, but that would let it compile

tony.kay19:12:10

which is probably your issue

tony.kay19:12:28

not that you use the function, just that the name cannot be resolved during compile

tony.kay19:12:50

so just interning that symbol to nil in the transit ns would prob make it work

tony.kay19:12:07

(assuming you don’t use that encoding function yourself)

codonnell19:12:13

Yes, that should work, as well. Interesting idea, thanks.

tony.kay19:12:41

something like:

(in-ns 'cognitect.transit)
(def write-meta nil)
in some ns that loads before that one

👍 2
Jacob O'Bryant19:12:31

re: the need to exclude clojurescript-- it's nothing that would need any change from fulcro. datomic ions just forces an old version of org.clojure/tools.reader, and clojurescript includes that lib AOT-compiled, so they conflict. Ideally the datomic deps would just get upgraded, but excluding clojurescript is easy enough

henrik20:12:19

Don’t hold your breath for upgraded Datomic deps.