Fork me on GitHub

Hey guys, does fulcro work with java 9?


I’m on java 9 and it works for me, provided i introduce some java options for compatibility


@wilkerlucio I’ve pushed a new branch with the large-db perf issue (the original unmount issue is on branch master).


@pithyless just checked the performance issue: 1. I can reproduce the slowness, the main cause is that the map inline render was unbounded, and since was in your root it caused the UI to get unusable, to fix this I now limit the number of inline items on map (10), you can try the latest snapshot with that 2. I tried adding a counter so I can test UI performance on refresh, I noticed while inspect open it gets real slow, but once I hide inspect (ctrl-f) the app performance got back good, I was unable to reproduce the "leakage" part


another tip: I saw that you created your own version of the package, another way to do is just add the local fulcro-inspect src path on your :source-paths, shadow-cljs is good with that (keep the latest fulcro-inspect on your deps still)


changes for the counter UI:


--- a/src/main/demo/ui/root.cljc
+++ b/src/main/demo/ui/root.cljc
@@ -44,7 +44,8 @@
       (dom/div nil
         (dom/button #js {:onClick (fn [e]
                                     (m/set-integer! this :ui/ping-number :value (inc ping-number))
-                                    (prim/transact! this `[(api/ping {:x ~ping-number})]))} (tr "Ping the server!")))
+                                    #_ (prim/transact! this `[(api/ping {:x ~ping-number})]))}
+          (str (tr "Ping the server!") " " ping-number)))
       (meaning-render this marker-table :life life)
       (meaning-render this marker-table :universe universe)
       (meaning-render this marker-table :everything everything))))


is there a way to force emacs to indent the (dom/blabla #js {} ...) functions differently? It now automatically indents these as option 1 or 2, but i'd like to have it autoformat as option 3:

;; option 1
(bs/container-fluid #js {}
                    (bs/panel #js {}
                              (bs/panel-heading #js {}
                                                (dom/h2 #js {} "Overview"))
                              (bs/panel-body #js {}
                                             (dom/p "Lorem ipsum" ))))

;; option 2
 #js {}
  #js {}
   #js {}
    #js {} "Overview"))
   #js {}
   (dom/p "Lorem ipsum" ))))

;; option 3
(bs/container-fluid #js {}
 (bs/panel #js {}
  (bs/panel-heading #js {}
   (dom/h2 #js {} "Overview"))
  (bs/panel-body #js {}
   (dom/p "Lorem ipsum" ))))


thanks! that does the trick


@wilkerlucio The fixes in alpha6-SNAPSHOT work for me. I’ll look into the leakage another time. Thanks! 🙂


@tony.kay RE: editor indentation. Would you be open to a PR that introduces {:style/indent ..} metadata into fulcro? David Nolen rejected the idea in om, but now that 2.x does not directly depend on it we could reconsider. Specifically I’m talking about something like IMO, it would be nice if fulcro encouraged a certain default indentation style for all the macro and dom elements, as it would be one less thing to trip over when selling fulcro to colleagues (who use various editors).


@pithyless FWIW i have seen different indentation styles in CLJS


perhaps it doesn’t make sense to define indentation rules, especially when it’s easy enough to configure most editors yourself


I’m not opposed to it. It doesn’t hurt anything, esp if it just affects the dom node generators.


Anyone know if this does “bad things” to others?


or would generally annoy some subset of cider users that think “1” isn’t what you should use…it should be ??? I definitely don’t want to get into editor indentation wars.


Fair enough, I just assumed that everyone was indenting things like dom/* and the macros (`defsc`, defmutation, etc.) the way it’s written in the guide (and I’m assuming here, the way Cursive auto-formats it). If that’s not the case, then I don’t want to start a bikeshedding competition. 🙂


When using the new form state support (, is there a good way to re-render the topmost form when making changes to a subform? I validate the whole form in my topmost form to see whether my submit button should be disabled and it doesn't update when editing my subform since m/set-value! and friends only schedule the edited component to re-render. I guess I could fall back to using the m/set-props mutation and tacking on a follow-on read, but that seems tacky.


what seems tacky about a follow on read?


i think it’s explicitly built for situations like this


I guess I just don't like losing the ability to use set-value! helper functions since they seem built for updating input state.


I just wish that m/set-value! had a :refresh option.


@U0LSQU69Z there is the direct mutation way to use the set-value:

(prim/transact! this [`(mutations/set-props {:foo "bar"}) :refresh-here])


@wilkerlucio Thanks, but there's still extra legwork you have to do when using m/set-integer! for instance. m/set-value! and m/toggle! map to their mutation equivalents pretty closely, but m/set-integer! and m/set-string! contain functionality that you have to rewrite when you need to add a follow-on read.


So, the helpers were added as a quick way to deal with local UI (not persistent) props. I never intended them to be used as non-ui data manipulators like this. The API could be extended, but at the same time it is trivial to add your own mutation for this, and also include a co-located (refresh ...) section to get the behavior you want. That also gets mutations into your data stream that make more contextual sense for the operation in question. Chances are you’ll also want to integrate other operations with certain field modifications, and would end up writing those custom mutations anyway. I would consider a refresh list for those helpers if it can be added without hurting existing API.