This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 100-days-of-code (1)
- # adventofcode (21)
- # announcements (2)
- # beginners (44)
- # calva (1)
- # cider (2)
- # cljdoc (16)
- # cljs-dev (70)
- # cljsrn (29)
- # clojure (66)
- # clojure-austria (1)
- # clojure-europe (4)
- # clojure-finland (1)
- # clojure-hamburg (1)
- # clojure-italy (24)
- # clojure-nl (3)
- # clojure-uk (127)
- # clojurescript (30)
- # core-typed (3)
- # cursive (34)
- # data-science (2)
- # datomic (16)
- # duct (17)
- # editors (1)
- # emacs (4)
- # figwheel-main (4)
- # fulcro (40)
- # hoplon (2)
- # instaparse (5)
- # kaocha (4)
- # leiningen (1)
- # luminus (4)
- # nrepl (46)
- # off-topic (5)
- # onyx (2)
- # other-languages (55)
- # parinfer (3)
- # protorepl (4)
- # re-frame (33)
- # reagent (6)
- # reitit (13)
- # ring-swagger (5)
- # shadow-cljs (26)
- # spacemacs (4)
- # sql (8)
- # testing (27)
- # tools-deps (21)
- # yada (1)
Someone was having a weird issue with state machines…was that @levitanong? ANyway, I found a race condition that might have been your problem…making a release
Problem persists, unfortunately 😞 Still working on that minimal repro repo. Hopefully will have one in 6 hours
Issue posted with minimal repro: https://github.com/fulcrologic/fulcro-incubator/issues/13
@levitanong So, how are you even compiling this? There is no package.json, and shadow-cljs isn’t in the deps.
Hmm… I guess it compiled because i have the global shadow-cljs thing in my npm. Sorry about that! Odd, it really wasn’t working when i ran it. Some console statements weren’t triggering as expected, or were printing out of order. I’ll revisit the repro repo and add more resolution.
Also, oddly, I received emails about your comments on the github issue, but when I visited the issue on github, all your comments disappeared. 😮
Feel free to contribute a library that does so. The Fulcro UI state machines I’ve built serve the needs I have at the present time, and I felt that HSM and such were probably overkill for most application in Fulcro. If that proves to not be the case, then we can always expand them, but I have limited time, and the fact is the way I’ve implemented them allows you to easily create state “parallel” state machines that involve given actors, even with overlap, so you can avoid state explosions etc. Besides, if you want to use that library, go for it! There is nothing keeping you from exporting CLJS functions that can be called from it.
What is the easiest way to revert mutation in case of a remote mutation failure? I am using pathom and it returns :com.wsscode.pathom.core/reader-error, not sure how to handle it..
@nbdam if you’re using incubator’s pmutate, you can add an error section to your mutation
that’s by far the easiest…otherwise you should probably use
ptransact! and add a mutation that checks the result.
I have performance woes! In a webgl + fulcro app I'm working on there's a view-state property that tracks the camera, by moving the mouse we change the camera. I decided this was best done in react local state. However I noticed just updating local-state is very slow! If I
prim/update-state! it takes anywhere between 80 and 150ms.
@bbss in general, animations are not a good thing to handle using the react render cycle, if you want real smooth animations you gonna have to do by manually manipulating the DOM, what you can do is use react to shield the users from seeing all of this, but every effective animation library I know has to do this
I have an example on fulcro inspect, I do something in this direction to provide the drag handlers to resize panels
ah, sorry, I though I did but seems like I setState was enough for me on this case, I remember using it on some old version of inspect (when it was in the page)
I've stopped using fulcro inspect because my state object was really big and the inspect was very slow.
We have animation done with requestAnimationFrame and shaders in that read a uniform, managed by the webgl framework, it's quite fast.
setState just calls render again with updated state, which should be fast because the state object is small. If I time the root render it's mostly below 2ms so that's fine too.
Does calling setState somehow cause a recalculation of props from app-state or something?
shouldn't, afaik it just triggers a render, had you tried using the react profiler and see if it gets any insights?
Ah, using a different way to update the view now, @wilkerlucio indeed not updating the props in the render. Performs way better, kinda unexpected that it can't be fast just through regular setState.
the set state stuff should not cause much Fulcro overhead, but I do agree with Wilker. I’ve got an opengl project as well, and I don’t do the opengl rendering mixed with react. I have a fulcro component that mounts the canvas, and lifecycle that initializes the opengl “subsystem” (my code that controls the GL). I then have an external custom “reconciler” that watches Fulcro state atom to sync any graphics objects that are controlled by Fulcro with the low level js stuff that is the mutable opengl stuff.