Fork me on GitHub

Hello everyone! Can anyone help me figure out why I always get nil for test-visible? below:

(defsc TestComponent
  [this {:keys [ui/test-visible?]} _]
  {:ident [:test/query :db/id]
   :query [:db/id
   :initial-state {:ui/test-visible? false}}
    {:size    "compact"
     :onClick #(do
                 ;; test-visible? is always nil
                 (prn "clicking test " test-visible?)
                 (m/toggle! this :ui/test-visible?))}
    (str "Test"))))

(def ui-test-component (comp/factory TestComponent))

;; called in a form
;; ...
(ui-test-component (comp/computed state
                                  {:on-change #(m/set-string! this :test/query :event %)
                                   :on-blur #(comp/transact! this [(fs/mark-complete! {:field :org/test-query})])}))
;; ...


Not many possibilities. You didn't compose initial state to root. You didn't compose the query to root, you didn't pass the props right from the parent.


Thanks @U0CKQ19AQ ! Problem solved by following your advice. I added {:ui/test-component (comp/get-query TestComponent)} to query, :ui/test-component (comp/get-initial-state TestComponent) to initial-state and passed ui/test-component in (ui-test-component (comp/computed test-component ... from the parent


:ui/test-visible? is a state local to TestComponent, do you think I should use :initLocalState instead?


Up to you. Component local state isn't easy to manipulate outside of the component, say in a mutation, and it goes away on unmount or remount. I use it on occasion... Just be aware of the tradeoffs.

👍 1

Thanks a lot!


@lichen2080 I'm kind of doing a driveby because I'm about to log out. But I'd start by using Fulcro Inspect to see if :ui/test-visible? is set in your DB. Even though you have :initial-state for this component set, unless we can see the initial state of all the components up to your root, it's hard to know if your initial state is actually being used. That would be the first thing I'd check: is initial state being composed in the whole tree of components above TestComponent.


You are right, something is wrong with :ident . I find the value is set in a map which corresponds to a nil key


@holyjak Thx for a great presentation at re:Clojure yesterday. I have gone through the Calva setup for the demo code, and followed the steps. However I keep getting a ‘Socket Closed’ error when I try In Calva, execute _Calva: Connect to a Running REPL Server in the Project_ - select shadow-cljs - accept the default localhost:9000. with a long stack trace (see below) The web app still runs fine throughout though, but I can’t proceed to the next step in the tutorial. Any idea? Thank you.. … (terminal output from successful build onward): [:todomvc] Build completed. (260 files, 0 compiled, 0 warnings, 7.47s) 09:47:20.210 INFO [io.undertow] (nREPL-session-a4078f1c-626e-433f-96d3-c53d437fcf8d) starting server: Undertow - 2.2.4.Final 09:47:20.214 INFO [org.projectodd.wunderboss.web.Web] (nREPL-session-a4078f1c-626e-433f-96d3-c53d437fcf8d) Registered web context / ERROR: Unhandled REPL handler exception processing message {:op close, :session a4078f1c-626e-433f-96d3-c53d437fcf8d} ERROR: Unhandled REPL handler exception processing message {:op close, :session a8594d04-4d50-4495-8897-3b2536896f18} Socket closed at at at at at nrepl.transport$bencode$fn__21613.invoke(transport.clj:121) …

Jakub Holý (HolyJak)15:12:49

Went do you connect to running repl instead of starting it from Calva, as recommended?


Hi Jakub, I realize I confused the terminal option and Calva editor hook-up to the terminal as being part of the Calva-only setup - I simply restarted and ignored the entire teminal option and have been progressing through the exercises. Thank you! If I can eventually make this work with Emacs/CIDER it will be a blast to use Fulcro :)

🎉 1

Just to clarify, it might help to number the steps in the setup instructions, so as to clearly delimitate the calva setup (e.g. step 1), terminal + calva editor hookup setup (alternate step 1), then the shadow-cljs diagram and relevant ports section, then troubleshooting. Maybe just bigger, really obvious headers might do it ? 🙂 Anyway thanks again for your patience and help !

👍 1

I'm toying with the dynamic-router and state machines right now and noticed the set-force-route-flag! on dr/retry!. It seems to me this flag is never reset? And indeed, when I retry! a route once in a master/detail view this flag seems to persist and :route-denied on my form is never called again. So, am I doing something wrong in how I use the routing system, or am I supposed to clear that force-route-flag myself? (which I'll do for now as a workaround)


I honestly don’t remember even making the flag…so it could be a bug 😄


Fair enough! 😄 I'll look into RAD the next days and see if I can figure out a place to properly reset it