Fork me on GitHub

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


Yes that was me :) Hurrah! Will check. Thanks!


Problem persists, unfortunately 😞 Still working on that minimal repro repo. Hopefully will have one in 6 hours


@levitanong So, how are you even compiling this? There is no package.json, and shadow-cljs isn’t in the deps.


Also, this seems to be working, though it does give a console error that isn’t true


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. 😮


My comments were mistaken…found and fixed the bug.


sorry for the noise


Ahhh no worries! As always, thanks for this awesome lib 😄


welcome. thanks for the reproducible case…makes things much easier to track down

👍 1

UI State machines 0.0.18 on clojars


Wondering if you’ve seen this, @tony.kay


Interop with this would be awesome, given their interop with!


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.


thanks.. will look into pmutate


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 time the prim/update-state! it takes anywhere between 80 and 150ms.


Using React .setState which is what update-state! wraps is also slow.


I switched it to props with a mutation, but that's no better.


@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


let me get the code for you


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)


not hard, just give some work


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.


So I'm kinda scratching my head why updating setState takes so long.


I'd think 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?


Using chrome profiler now, I'll try the react profiler.


Ah, looks like timing the setState includes the render call.


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.