Clojurians Log v2

Thanks all.

the multi-root stuff relys not on OO stuff, but react hooks. Not sure what you mean by OO react stuff. The hooks stuff is all functional. But yes, they are being used to create an on-mount and on-unmount lifecycle. That is not really in the purview of Fulcro itself, but something you should probably implement in your rendering layer…notifications when something is on-screen, and when it leaves the screen. You could also tie those events to mutations, which puts you in the Fulcro txn system. A diagram of the default (pluggable) tx system is https://github.com/fulcrologic/fulcro/blob/develop/src/main/com/fulcrologic/fulcro/algorithms/tx-processing-readme.adoc

most of tx processing is around full-stack integration…there’s really not much to it for pure UI: put the tx in queue, run optimistic things.

There’s no mess of other event based stuff

so, really simple: (transact EQL) -> submission queue tx node -> activation (runs all optimistic actions, queue sends) -> render

see docs on React hooks. You might be able to implement something like that, which would make it more approachable for “standard” fulcro users.

does transact! run synchronously when you call it. if I had a pre draw step that ran some transactions, could that be an option?

Holy smokes. Again, thanks to lots of DMs with @holyjak and about 5 hours of hacking away, I finally got my first multiple cardinality join working (which now, looking back, was primarily because I misunderstood the EQL syntax…) But 15 minutes later, thanks to fo/query-inclusion, I got my form working to display tags for conference sessions. That’s pretty incredible. I’m starting to see the magic that Fulcro RAD enables! Kudos, @tony.kay! (Posting screenshot to share feelings of triumph…. mid-afternoon, I was seriously thinking, “how can I spend 25+ hours on this, and not even able able to do a join? maybe Ruby on Rails or perhaps even learning PHP might be a smarter choice…“) Onwards! 🙂

I think this could have some interesting repercussions for Fulcro: https://www.youtube.com/watch?v=TQQPAU21ZUw

Is there a way to force a root render on transact! ? I see that :`only-refresh` from different transactions are merged for the same transaction cycle (eg. 2 on-click event handler triggering roughly at the same time). So if one does not supply it expecting a full re-render while another does supply :only-refresh, things get messy

I suspect you’re over-using only-refresh. Do you really have a measured (production build) performance problem? Or are you prematurely optimizing in dev mode?

This is pretty much my first attempt trying to solve long delays on some click events. And it does solve them. But as such, it screws with any other handlers triggered at the same time, which is not uncommon given the hierarchical nature of the DOM.

I was hoping for a :force-root? option somewhere. Well, to be more precise I was first expecting that this problem would not exist, it's only after watching on the runtime atom that I noticed the merging (and after reading the source a bit, I understand why)

It seems I can either not use only-refresh at all, or have to use it everywhere (talk about over-using then 😛 )

you can supply your own transaction processing (e.g. wrapping the default one) and do what you want/need there, such as adding support for :force-root?

v2 of https://blog.jakubholy.net/2020/troubleshooting-fulcro/ published, with focus on troubleshooting the backend, i.e EQL resolution in Pathom. Diff: https://github.com/holyjak/blog.jakubholy.net/commit/307850120a4253b1ec8e96a644204ee4bc9ea840#diff-872e80ad034756ce7edc137851745c47a67a8aa43b2c25857408166f8a161ce4 Also added this section, and I am curious what you think about it: > Fulcro is fundamentally simple and so is, in essence, troubleshooting it. It consist of a number of small, simple parts connected together. All problems stem either from not using a part correctly or not connecting them correctly together (the price of Fulcro being more library-ish then framework-ish). The key to troubleshooting is then to find the relevant part and zoom in on it and then to check all the relevant connections up to the UI. And you need to know how to optimally troubleshoot these various parts. > An early distinction to make is whether it is a frontend problem (mostly a matter of the correct query/ident/initial state/composition into parent) or a backend problem (mostly a matter of resolvers and their registration with Pathom or the underlying data sources). > For example. if the UI is not displaying the expected property, you might find out that it is because the server does not return it (connection). You zoom in to the resolver responsible for it (the simplest part) and the DB query it calls (even simpler sub-part) - is the query working? Is the resolver working? Is the resolver registered with Pathom? Is the query actually correct? The wrong solution is to stay at the level of the UI and work with the full stack while trying to locate the root cause of the problem. > Stuart Halloway’s https://youtu.be/FihU5JxmnBg: offers a great approach to such a troubleshooting. > It is crucial that you know your tools so that you can really focus on the relevant part of the sytem and to explore / invalidate a particular hypothesis about it and the cause. Primarily this means that you need to have Fulcro Inspect working and be familiar with its many powers.

you do not need to go that far…I guarantee you’re running into something that has a better sol;n

I’ve never personally needed :only-refresh

and very very rarely a forced root render

Really? it's advertised as such an improvement over KR1. (by forced I meant ignoring only-refresh, not disabling sCU)

The app I am working on currently is already doing too much (generating MIDI events, animating a full screen canvas, cannot get help from a webworker, and quite a lot of DOM stuff...), so things can get a bit out of control if I am too careless about the DOM

@holyjak Indeed, it looks like I can pretty much copy/paste the default one and simply make it ignore any :only-refresh once it encounters a trx which doesn't have one

Right, the overall system is designed to be fixable in any of those ways (use the optimizations I’ve given, or tweak them to your app). However, I would start by trying to measure things. I’d also try the syncrhonous txn processing. You might find that you’re over-rendering, and should split some components up in order to get SCU improvements, etc.

so while I don’t know your code, my experience is that with some good measuring (use CPU performance tab of Chrome to start) you may be misunderstanding the performance

Inspect has a lot of overhead at times in dev, for example. You might be seeing something that doesn’t even show up in an advanced prod build

as does Guardrails

and debug loggin

etc

figured out, was missing adding the attributes in the attribute list at the end of file :man-facepalming:

Good point. My Fulcro app is sometimes also slow in dev but OK in prod.

I have created the long overdue https://github.com/holyjak/awesome-fulcro/ Please send your PRs with more resources!

I started a https://github.com/souenzzo/eql-style-guide