This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-01
Channels
- # announcements (5)
- # aws (2)
- # babashka (35)
- # beginners (68)
- # bristol-clojurians (1)
- # calva (14)
- # cider (9)
- # clj-commons (5)
- # clojars (3)
- # clojure (101)
- # clojure-australia (6)
- # clojure-europe (35)
- # clojure-italy (2)
- # clojure-nl (5)
- # clojure-spec (1)
- # clojure-uk (4)
- # clojurescript (70)
- # conjure (3)
- # cursive (7)
- # datomic (36)
- # emacs (11)
- # exercism (1)
- # fulcro (23)
- # helix (2)
- # jobs-discuss (15)
- # lsp (17)
- # malli (8)
- # meander (1)
- # nrepl (60)
- # off-topic (10)
- # pedestal (9)
- # react (8)
- # reagent (53)
- # reveal (10)
- # shadow-cljs (27)
- # spacemacs (4)
- # tools-build (4)
- # tools-deps (4)
- # xtdb (2)
What's the default renderer in the latest fulcro release ? Is it still ident optimized or keyframe renderer ?
Now that we have React hooks and the related Fulcro support I'd lean more towards that and less towards the specific rendering plugin.
The multi-root renderer was an attempt to get disconnected (from the query tree) components into the middle of applications, and RAD uses that a tiny bit; however, the support for things like use-component
are much more effective and easy to reason about...and they don't require a rendering plugin:
https://book.fulcrologic.com/#_dynamic_lifecycle
I also found a really fast way to do props diffing on those, so the performance is quite good.
thanks @U0CKQ19AQ. I was watching Fulcro 3 tutorials and so was confused as to how to go about using derived values.
The Fulcro model is very very simple on that front: UI is a pure f(s), where f
is denormalizing the database. Period. There are no intermediate hidden wheels/gears/knobs. The view is a direct result of the data in the state map. If you want derived values you can:
1. derive them as pure calculations in the view (the most common). js is very fast, and many derivations work quite well that way and are trivial to get right and debug.
2. Cache the derived values in the state map at a well-known (and queried for) place, and define a lifecycle for that derived state. UISM is very nice for doing that. Good examples are RAD forms and reports. They come with state machines that do all manner of intermediate processing at well-defined interactions, and are self-contained. You can also use entry points like router will-enter, React lifecycle, hooks, etc.
3. You can use any the facilities of (2) and various customization points of Fulcro’s internals to add something more complex. I’ve never wanted/needed such a thing, but it is totally possible. For example, a really simple one would be to add a watch to the global state atom and watch it for certain changes and auto-derive state, then trigger a refresh (even a targeted one if you use the indexes) of the UI. Fulcro watches that atom in dev mode for Inspect, but does not use watches on the atom for any other purpose itself (e.g. swaps on the atom do not cause rendering…which is why you’d have to schedule a render yourself. The tx processing system is primarily where ui refresh is scheduled from).
Thanks @U0CKQ19AQ. I'm still coming to grasp with how everything in Fulcro is a function of state. I'm going through all the tutorials and they contain a lot of gems, but require multiple viewings to put everything together cohesively in my mind. Thank again for the videos, they help a lot to clear concepts. Cheers 🙂
And thanks for being so responsive and proactive on this channel. 👍:skin-tone-3:
> defaults to multiple-roots-renderer
https://github.com/fulcrologic/fulcro/blob/develop/src/main/com/fulcrologic/fulcro/application.cljc#L166
It seems I have committed myself to hold a 1-2h Intro to Fulcro workshop at the coming re:Clojure 😅
Good morning all! I have a design question. I am building a mobile-first web app. I have several screens of forms that will not be submitted until the last screen is filled out. Each screen has a route. What is the best way to organize my project so that I can submit the data correctly from these screen when the front-end is in the right state?
So, I would tend to make it a single form (with subforms) so the state can be managed as a single "unit", then do the rendering according to what "page" you're on.
something like
(defsc Wizard [this {:ui/keys [page] :as props}]
{:query [:ui/page fs/form-config-join ...]
...}
(case page
1 (dom/div ...)
...))
is one wayIf you really want a collection of related components to work together towards a goal, then yes, I'd definitely use a UISM
Thanks @U0CKQ19AQ !
Hi all, I am getting an odd resolution error in IntelliJ on a new fulcro-rad template project, it looks like the mount defstate
macro is somehow not expanding properly. I've never seen this issue in the IDE before. Update: In fact, no expressions defined via macros as opposed to functions are being resolved. Maybe there is an easy IntelliJ/Cursive setting I am missing?
could also be a problem with your project overall, but macros that are not part of core may not be understood. In that case choose the quick fix, resolve as..., and choose the existing macro/form that is already understood. Most macros look like def
or defn
or let
....so just choose the one that best approximates an existing one.