I’m happy to announce Fulcro 2.6.0 is on Clojars. This new release includes a complete rework of the internals to work with React 16's new lifecycle methods, and should be forward compatible to React 17 when it ships. There is a subtle difference with how component-local state behaves (React made this async), so it it possible you could see breakage if you rely on getting state right after setting it in the same sequence. I also refactored the CSS internals a bit to ensure that garden does not bloat adv compiles of cljs when you do not use component-local CSS. Users of the old defui notation will have to rename their protocol usage.

do I need to add something besides the fulcro.inspect.preload for it to work?

I have the chrome ext installed

and it logs Installing Fulcro Inspect ... on startup

but chrome ext still complains about not finding it?

and says No app connected.

ah nvm. it doesn't seem to like <script async>

works without

There were some issues importing Fulcro's API into cljdoc recently which have now been fixed: https://cljdoc.xyz/d/fulcrologic/fulcro/2.6.0

question about fulcro mutations: how common is it that remote returns anything other that true/false?

the client side (remote [env] ...) thing I mean?

@thheller Might be difficult to find out how common it is without having a survey, but in all my work projects (where I interface with a REST api) I have to perform some witchcraft of the sort.

ah right

@thheller I use it relatively often. The returning/`target` is particularly useful when you want a mutation to update your state from the server’s return value.

that, combined with ptransact! (to defer a mutation until after the remote has completed) allows for more complicated scenarios of UI reaction to server responses

(ptransact! this [(m-with-remote-and-return) (post-mutation-to-analyze-result)])