This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (2)
- # architecture (16)
- # babashka (26)
- # beginners (106)
- # calva (172)
- # chlorine-clover (19)
- # cider (36)
- # clj-new (7)
- # cljdoc (4)
- # clojure (113)
- # clojure-berlin (3)
- # clojure-czech (3)
- # clojure-dev (5)
- # clojure-europe (37)
- # clojure-france (3)
- # clojure-hamburg (12)
- # clojure-italy (4)
- # clojure-nl (2)
- # clojure-uk (22)
- # clojurescript (38)
- # cryogen (10)
- # cursive (30)
- # data-science (7)
- # datascript (1)
- # datomic (13)
- # depstar (13)
- # duct (3)
- # events (2)
- # exercism (3)
- # fulcro (31)
- # graalvm (56)
- # graphql (1)
- # helix (5)
- # java (12)
- # jobs-discuss (19)
- # kaocha (13)
- # luminus (1)
- # lumo (4)
- # malli (5)
- # off-topic (17)
- # parinfer (1)
- # pathom (1)
- # pedestal (7)
- # rdf (10)
- # re-frame (1)
- # remote-jobs (7)
- # rum (6)
- # shadow-cljs (4)
- # tools-deps (41)
- # uncomplicate (3)
- # vim (14)
I dunno what I'm doing wrong but example 1 from the book doesn't work since I upgraded the versioning. I don't want to downgrade since it's probably something dumb that I'm missing, but I have no idea what.
the num updates but the updated value isn't passed through the component I think? i'm still not really sure, I'll try again tomorrow.
Fulcro 3.3.4 is on Clojars. This version fixes a regression in some networking requests that was caused by a bugfix in EQL (v0.0.9->1.0.0)
Also, if anyone cares to comment on this: https://github.com/fulcrologic/fulcro/issues/400
I’d love to hear from you. Right now transit supports all of the built-in types and Fulcro tempids, but customizing types means you have to drop extensions in everywhere you use transit-related things (transit-clj->str, http-remote, websockets, etc.).
With RAD, there is a further desire to be able to customize these centrally and more easily since a library author might want to provide fields/controls that use some custom type (e.g.
#time/local-date). Being able to centrally define what data types you support and how they are encoded and decoded in all the various spots is becoming more and more important (RAD route parameters, for example, encode current control state in the URL for reports using Fulcro’s
transit-clj->str followed by a base64 encode)
I’m torn between a central registry (which would make it easier to cover all of the bases for you, but means you have to remember to install your things) and a non-side-effect implementation where you’d have to at least pass a config map to all of the things (which means you have to remember to pass that config at every call site)
The latter has the small advantage (from a purist design perspective) that two apps on a page could install different transit things and not conflict…but that should be really rare, and also fairly easy to fix if you control the source of at least one of the apps on the page.
Hi all, any thoughts on how to achieve the following?
Computed props that are only calculated on the client that are derived from a nested structure.
Goal is to calculate the cost of a product.
The product has a nested material structure.
Burrito −> Spicy Beans −> Cooked Beans −> Raw Beans
Is there a way to show a view of the Burrito, say name and price, and if the cost of
Raw Beans changes, it would propagate a change up to the top level?
In my attempts with RAD, I see the derived field like
total−sum* example, but I don’t see how I would deal with sub items under that to trigger a change.
Example: a diff pushed in from remote update, that now invalidates and changes the derived data.
A component has the entire tree of props. In RAD, derived calculations would need to happen in the ultimate parent form (which can see everything). So the price of your burrito is just the sum of the prices of the children, which are all visible in the props of that top-level form.
Would it be possible to grab the db atom and use an atom-based reactive graph lib to hold calculated values?
I’m working on a design for that kind of thing, but using the atom directly in UI will not work with rendering
In this case, though, I still would not recommend it. A combination of a quick specter query and a sum gets you what you want…what could be more declarative than:
(let [prices (sp/select ... props) total (reduce + 0 prices)] ...)
The list kind of changes continuously…I used “3” to generally rate where I think it lands in importance, but in terms of timeline, that could be quite different due to other things like free time etc. Fleshing out more of RAD is probably higher on the list ATM
so far the only place where I see it being really useful (dependent data calc fw of sorts) is in complex reports, where the data you got from the server needs some major work to fit the UI needs. Right now you just have to mutate it into shape, and re-run the mutation to update it.
but I just haven’t seen a design for that yet that I care for. Fulcro has tools that other libs don’t have, so leveraging the data normalization and query power could add a lot to the equation.
Thank you @U0CKQ19AQ - If I’m rendering a burrito though, will a change in raw beans (3 levels down like I outlined, via websockets) trigger a new sum-total* call?
Lastly, would it be performant in your opinion in a situation when I have Burrito, composed of 15 sub components, and in term more sub components, basically a complex multi level bom system with cost - if I am recalcing on every change anywhere in the tree?
Our current solution that I am porting over has each level of the BOM memoized so we only re calc impacted branches
1. A change 3 levels down will still be rendered from parent in RAD, so yes. 2. IMO, premature optimization. You’re memoizing something that might be composed of 100 gets and a sum? Js is fast these days. That prob takes like a few hundred microseconds. I’ve done filters of 8000 items in the UI without memoization on modern browsers and had it be fast enough.