Fulcro 3.0.8 is out, with a few bug fixes, and new support for easier binary return values from server mutations: http://book.fulcrologic.com/fulcro3/#_binary_return_values

@tony.kay I'm getting a stack trace in the browser for "3.0.8", but not for "3.0.6". I've got a little one button application that illustrates. I know that I did not see this failure for "3.0.3" - my current project works fine at "3.0.3". My guess is that it is a timing / project size related problem. I'm not running on a fast machine. Anyone else who tries might not get the same problem. It is setup for failure at the moment, at "3.0.8": https://github.com/chrismurrph/tempids-test.

do you have the full st? That is an abbreviated one

nvm…I can reproduce

ah, this was a change to a DOM helper to make it more efficient

clearly it isn’t quite right

@cjmurphy Upgrade to fulcro-garden-css 3.0.7

it still has some internal issues I need to resolve….the param support just isn’t quite right

Got it. Yes 3.0.8 with fulcro-garden-css 3.0.7 works fine on my main project. Thanks.

So, I had done a recent optimization that didn’t cause problems for me, but it was only because I didn’t end up running it 😜

The optimization makes DOM elements, when used as functions (not macros) to take 3 microseconds each (the old ones take nearly 3ms each.

and I wrote tests, but I didn’t A/B compare the old output with the new 😕 So, I thought they were right, but in fact they were very different

So, I put the old impl in the test and had the tests do A/B comparisons…that should fix it.

Try Fulcro 3.0.9-SNAPSHOT @cjmurphy

that seems to work for me in about every combination I can think of

I’ll make a new release

3.0.9 Released. CSS Localized DOM factories should now be roughly 1000x faster than they were before. The non-macro version of the DOM factories had a call to clojure spec in them that was very slow. This didn’t affect regular DOM that often (the macro is usually used), but it did affect garden-css dom elements. This will also speed up any functional application of regular dom factories (e.g. (map dom/li …)) by the same amount.

This is more of a query for opinions, but I was wondering how to best handle a common case in my app where I need to call into a 3rd party JS API I don't control, but to do so I need to make some heavy use of the App DB state for mainly query purposes, not actual mutations. Is it better to handle all these cases via mutations given I often don't need to change the App DB itself during these operations? Technically, many of these operations change the UI but not through my own code. I'm slowly trying to hijack what I can and control it with a data-driven approach, but some of it is just not possible/will be a performance nightmare. There are some benefits I can see up-front like making it easier to transition where I can to data-driven approaches and to introduce things like instrumentation, however I could just kick off some additional mutations from elsewhere I suppose.

I’m not a fulcro expert in the slightest, but I think pushing any third-party APIs to the backend with Panthom resolvers might be the best move to keep the front-end patterns consistent

well the actual work in the mutations, at least for the part I'm talking about has to be work on the front-end

a good example - changing the cursor position in an editor component

the thing is the actual actions are kicked off asynchronously by a dispatch mechanism that only the editor controls so there's no "click" event type thing in the UI to listen for

A third-party API is driving the cursor position?

yeah, the 3rd party component mutates itself and I do my best to track the pieces of state I need elsewhere, ex: by listening to keypresses and change events

Does the 3rd party component provide a “controlled” version?

but the thing I'm unsure about is the case where they kick off a lot of async actions (some of which are provided by me)

Where it doesn’t keep it’s own state

well I should mention it's also not a react component

state is everywhere inside it as it is a huge component

forking it would also be a pain as that in itself would be a project to keep up with the mainline

Sure

it has a sort of command system where it will kick off any commands I provide async, so I just did a first pass of a few as mutations and they work well, but at this point I'm realizing I can split out a ton of things outside a mutation when nothing is updated in the app db state

I’m not sure of the perf impact to be honest. But it may be worth minimizing interaction given you don’t need to mutate anything

the thing is that would require me to constantly reach for the "app" manually which is fine, but the mutation system sort of provides more convenient access and a bunch of other things that are handy

if I do the work inside a mutation, I also can at least see that something in the UI changed even if I can't really undo it without some manual steps sometimes

ex: the editor has its own undo stack so without double recording state changes, I have to call their undo stack to be in sync

I would use what it already provides.

Or find a simpler alternative, depending on your needs

(Is this DraftJS?)

nope

I'm just trying to proxy in a larger environment that uses this editor and adapts the environment's command system with the editors so there's no avoiding it really

it would be like in IntelliJ needing the text editor to integrate and respond to the same action system as the file explorer for example. It's not an IDE or anything, but there's some overlap of concepts and some editing that needs to be done so it's at least similar.

Gotcha

Hopefully someone can be of more help in this case.

well I think talking about it definitely helps as it stirs up some other thoughts in my mind, so very helpful regardless, thanks