This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (9)
- # announcements (5)
- # babashka (3)
- # beginners (46)
- # calva (21)
- # cider (15)
- # clj-kondo (20)
- # cljs-dev (57)
- # cljsrn (10)
- # clojure (147)
- # clojure-dev (6)
- # clojure-europe (3)
- # clojure-france (2)
- # clojure-italy (8)
- # clojure-nl (18)
- # clojure-norway (5)
- # clojure-spec (16)
- # clojure-uk (63)
- # clojuredesign-podcast (7)
- # clojurescript (65)
- # clojurex (42)
- # cursive (12)
- # datomic (10)
- # fulcro (47)
- # graalvm (102)
- # graphql (2)
- # jobs (5)
- # joker (12)
- # off-topic (33)
- # pedestal (6)
- # re-frame (6)
- # reagent (8)
- # reitit (6)
- # remote-jobs (4)
- # rewrite-clj (10)
- # shadow-cljs (86)
- # sql (45)
- # testing (4)
- # tools-deps (43)
- # vim (8)
- # xtdb (3)
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.
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.
Actually I got the same stack trace in my main project, this time when navigating to another page. So for now Fulcro 3.0.3 with fulcro-garden-css 3.0.7 is what works for me.
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.
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
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
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)
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
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'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.
well I think talking about it definitely helps as it stirs up some other thoughts in my mind, so very helpful regardless, thanks