Howdy. Yes, I was just thinking this the other day. That a general label could be used as a default, even though you might want a difference (report headings are typically more space constrained).

I have not implemented it yet. It’s mostly a rendering plugin update, of which there is currently only one 🙂 So, would not be terribly hard to do.

Did you end up reporting a bug for RAD initialization for that problem you were seeing in the RAD template?

no, will do now

Thanks

There are two primary ways to do this. If it is a true to one relationship, then you can simply make a resolver from person ID to address ID in pathom and then you can just include address things as columns. The other option, which works for any cardinality, is to use the report option ro/column-EQL and write a join that pulls the information you want to format in the column, and then supply a column formatter to do the formatting of the nested data

Thank your! So simple, so beautiful! :) I won't need column-EQL but it's good to know about it 🙏

Yes, this would have to be a custom control, though I would argue that the proper way to do it is to design a modal container for the form of the subentity. Such a modal would need its own UI State machine to control some of the interaction, including starting the form State machine, independent of routing. The one additional thing that you would need in this modal is the ability to pass either a lambda or mutation symbol that would be called once the new entity was created, so that you could use that to fill the form field at the core route

In other words the creation aspect would not use a subform of the primary form, but instead would start a modal and a completely separate creation form for this specific task

That makes sense, thank you!

I’m actually needing that exact control myself, and was planning on writing it soon. Perhaps we can collaborate on it?

I would love that!

what hours are you available these days?

FYI I am trying to work on this to learn before our session but am struggling with figuring out how to render the form inside the modal. I cannot really compose it all the way to the root so I experimented with a detached root for the form using hooks/use-root but that conflicts with form/start-form! , which expects the form to be under <ident> in the db. Perhaps I should use hooks/use-uism instead, with form/form-machine and ::uism/actors ... to hook it into the form?

Yes, because it is a disconnected root kind of situation you have to use something to get the props joined up, and also the whole tempid management is a bit of fun. Using a wrapping container with a constant ident via use-component did the trick for me. See the private message to you.

Anyone following along: See the pick-or-add branch of fulcro-rad-demo, and the com.fulcrologic.rad.rendering.semantic-ui.entity-picker ns in the SUI plugin (WIP)

I believe Fulcro does not support merging loads.

I think it does, as per https://book.fulcrologic.com/#_server_interaction_order

Notice the emphasis in > may be combined I believe F. did it once upon time but does not currently

So, Fulcro 2 did it, and Fulcro 3 can do it, but the support has never been tested really hard in production. You have to switch out the transaction processing.

see the batched-networking branch

I should really pull that in as a new one you can swap out in mainline development, but I’ve been busy with other things

as far as I know it works fine

I don’t recommend React 18 yet.

I have more pressing production issues in Fulcro ecosystem at the moment. Contributors are welcome to give a shot at something that will fix the issues, but I have no idea how hard it is likely to be. I thought just swapping out the initial render would do it, but it seems to break at least hot code reload.

which is a huge deal breaker for real dev

Thanks @U0CKQ19AQ. Just noticed that the React 18 docs mention that if you do not switch to using the new root API, then it will behave as version 17 did, which is actually fine. I didn't know I could have react 18 working in compatibility mode with 17 api, which works for my purpose as I was just having a dependency headache. Tried it now with React 18 dependency but without making the 'recommended' changes to use the root API and it worked nicely. Thanks again for the wonderful work with Fulcro.

Sure. I realized last night what the problem is. Fulcro was written originally with React 15, which was synchronous in rendering and had no support for “context” data. So, clj dynamic vars were used instead. The main problem this has caused all this time is that using async patterns for rendering (e.g. https://book.fulcrologic.com/#_the_function_as_a_child_pattern). It meant you have to manually fix the async breakage. BUT, with React 18 in non-compat mode ALL rendering can happen async, and those dynamic vars are just broken. The fix is to move that stuff into the React 16+ Context support, which is where it would have started out if all this code had been written a little later in history.

This is going to be a (minor) breaking change I think, since user-space code can see/use the dynamic vars, and they need to go away.