Fork me on GitHub

2.5.5-SNAPSHOT is on clojars. This is a test release of Wilker’s patch to mutation merges with tempids.


Anyone else having issues with the shouldComponentUpdate-lifecyclemethod?. It seems like im getting react-props instead of fulcro-props when the lifecycle method is being called. :shouldComponentUpdate (fn [next-props next-state] ..) I looked into the default implementation of this lifecycle method in fulcro.client.primitives and was able to retrieve the props in the same way: (.-props (gobj/get next-props "fulcro$value"))


Also noticed that there is no reshape-fn for this lifecycle method, might this be the problem?


The only thing I've ever wanted to override that for is to set it to false for turning off subcomponent rendering for things like d3. I did not notice the props we're right. The code for it should be identical to that from Om Next, since that's where it came from originally.


The built-in behavior is able to short-circuit if the props have not there should really rarely be a reason to override it. It should, of course, be fixed if it is broken, but in 3 years I've not seen anyone say anything, which sorta indicates no one is overriding it


yeah, the missing reshape is why you're seeing react low-level stuff...that should be fixed.


Fixed on develop...not yet pushed to clojars though

🎉 4

Great, thats why I was doubting if I was doing something wrong, how could no one have ran into this issue. I did find this though: Someone did ran into it in 2016


funny, and he closed it thinking it was “his problem” 🙂 So, Om Next still has the issue


hi everyone, I've been working on a full-stack implementation of the famous Realworld app with fulcro on the frontend and Duct+Walkable+Postgresql on the backend


Would be great if anyone can pitch in 🙂


The experience with Fulcro so far is superior. Many thanks to Tony Kay and Wilker Lucio for your hard work

🎉 20
🙂 4