noob question: I want my footer to become visible when the window is scrolled past a certain distance (let's say 1000px), and become invisible again when the window is scrolled back above that distance. The implementation of the visibility is pretty straightforward, on the footer I have:

(defsc Footer [this {:keys [ui/visible?]}]
  (dom/footer {:classes [(when visible? :.visble)]}
    ...content...))

I'm also not sure about whether I need ident, query, and initial state on the Footer component for storing :ui/visible? in the db, or whether that should all be on Root, or perhaps both?

@miridius For this sort of stuff I usually init the listener in new-fulcro-client and pass it the reconciler (transact! works with reconciler). You can add follow-on reads to the transaction for targeted refresh.

oooh nice

The ident should be up to you, how you structure you're app. If you store the :ui/visible? in the root and just pass it to the dumb footer (no query, ident), should work. If footer has query & ident, the operation might be cheaper since you could add a follow-on read to target the refresh.

ah ok, then I think it makes the most sense to give the footer a query and ident so that I'm not refreshing Root every time the user scrolls

Something like https://github.com/fulcrologic/fulcro-template/blob/develop/src/main/fulcro_template/client.cljs#L29 I usually pass the reconciler . Here I see the start-routing gets the root and the load gets app 😄 Think app and reconciler are interchangeable in this context.

thanks!

one more question: is it normal to give Root an ident, or is it more idiomatic to store its keys at the top level prefixed with :root? And if the latter, do you put the :ui prefix first or second, i.e. :root.ui/footer-visible? vs :ui.root/footer-visible?

Root like in this one https://github.com/fulcrologic/fulcro-template/blob/develop/src/main/fulcro_template/ui/root.cljc#L87 does not have an ident. I you need stuff that's in the top level in you're components you do the '_ stuff http://book.fulcrologic.com/#_using_data_from_root

mmm ok cool, I guess I should have spent more time looking at the template! Thanks 🙂

I think my mistake was to make the template with nodemo so I didn't see all this example code

these are just convetions so it's up to you http://book.fulcrologic.com/#_client_database_naming_conventions . The only one I know that has a meaning in fulcro is :ui/something. Since fulcro will elide it from the query sent to the server. But in the case of root you don't do df/load on it so adding :ui/root-prop1 has no special value there

hmm 🙂 the're two templates https://github.com/fulcrologic 😄 fulcro-lein-template & fulcro-template (this one is just a demo app)

ahh! 😄

nodemo was removed from fulcro-lein-template along with figwheel recently 🙂 it's just lein new fulcro project-name now, and you get the full setup with shadow-cljs

Is it always mandatory that any component initial state and component query has to be composed into the root initial state and root query for it to work?

the queries need to compose all the way up to the root.

inital-state is optional but if you want it there when you start the app then yep you have to compose it in the parent, and parent to it's parent etc...

I am trying to do a remote mutation with tempids. The response from remote is #:fulcro.client.primitives{:tempids {"tempid" 17592186045446}}

and the mutation was transacted on {:db/id "tempid" :morekey 3}

Where the ident is [:material/by-id :db/id]

Why isn't "tempid" updated in {:material/by-id}?

Hm according to the book (input :.ui.input {:type "text"})should work

But it somehow creates a text field that can't be edited

but (input :.ui.input #js {:type "text"}) works

what am I missing?

Has anyone used to the stripe elements stuff with Fulcro yet?

@roklenarcic input from what?

it's dom/input, html5 component

better question would be, when I use shorthand for classes in components, if I have additional attributes, do I pass them as js object or cljs map?

is there an equivalent to reagent’s adapt-react-class in Fulcro?

would that be similar to factory-apply?

is it an anti-pattern to query for the active state of a particular state machine, in a UI component?

i know i have the ability to modify an actors state however i like, so if i can’t query the actual active state i can put markers in app state in event handlers

The example for theming in the fulcro book uses an atom for pulling theme state. Can css-local-rules pull data for theming out of props somehow, or is the css generated at a point that would make that difficult?

Was getting an error attempting to use

{:css (fn [props] [[:.foo {:color (-> props :theme :color)}]])}