This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # babashka (94)
- # beginners (76)
- # calva (24)
- # cider (24)
- # clj-kondo (1)
- # cljs-dev (16)
- # cljsrn (45)
- # clojure (135)
- # clojure-europe (9)
- # clojure-france (5)
- # clojure-germany (2)
- # clojure-italy (12)
- # clojure-losangeles (13)
- # clojure-nl (3)
- # clojure-portugal (54)
- # clojure-uk (20)
- # clojurescript (55)
- # conjure (67)
- # core-async (5)
- # crux (33)
- # cursive (2)
- # datomic (7)
- # docker (7)
- # duct (22)
- # emacs (16)
- # fulcro (34)
- # graalvm (15)
- # hoplon (1)
- # instaparse (1)
- # jobs-discuss (3)
- # juxt (94)
- # luminus (1)
- # meander (4)
- # off-topic (13)
- # pathom (4)
- # pedestal (1)
- # ring (3)
- # ring-swagger (2)
- # shadow-cljs (61)
- # spacemacs (17)
- # specter (2)
- # sql (23)
I'm working on storing a date in the Fulcro db. Does anyone remember where in the Fulcro Videos Tony talks about how to maintain the correct data type between the Clojure backend and the Clojurescript frontend?
Hi All, I was having trouble explaining the idea of how Fulcro “composes” the UI from the database to a friend so I came up with the following explanation. Is this correct?:
Components form a tree with the Root component encapsulating all the other components. Each component is responsible for rendering one part of the sub-tree. To render the UI, the root component is handed a tree-representation of the application’s client-database (a.k.a. the application’s data). The root component picks out the data it needs and hands the rest of the data to its child components which in turn, pick out the data they need and hand the rest of the data to their children until all components in the chain are rendered. In this way, the UI is said to be “composed” from the root element.
Not bad, but any description of Fulcro that doesn’t mention normalization is ignoring its single most compelling feature IMO.
@mdhaney Thanks for the feedback… re: normalization - I avoided it on purpose so that I didn’t overwhelm the person with too many new concepts. The next step would be to explain how the database is structured and get into why normalization is so important etc…
is there a place in the docs that specifically talks about why normalization is so important?
sometimes it is easier to link someone to something than to explain it all to them (also I would like to read it)
@lilactown A good discussion is sections 3.8 and 3.9 of the Fulcro book: http://book.fulcrologic.com/#_updating_the_data_tree
Interestingly, and I’m not sure when, Apollo has adopted normalization as well…the idea is definitely taking hold in the wider world
which is funny, because we’ve been doing it in “real databases” for how many decades???? At least 6 or 7
I thought that was the major selling point for apollo? that it handles the complex caching of GraphQL queries
caching yes, but I’m not sure when they added normalization…was it always there since release? I thought the earlier releases had caching, but it was subtrees.
hey y’all, trying to debug a
transact! call not triggering a re-render using the vanilla keyframe renderer.
I have a parent component A, that renders a component B. B renders a modal C that is rendered via a portal.
everything works fine and dandy until I navigate away from and back to this view. after navigating back, when calling
transact! inside A to render B/C, the data is updated correctly in the db (i.e. modal should be rendered), but updated props are not being fed to B/C.
I’ve attempted to add the idents for B and C into as
:refresh options to the
transact! call in A, but that’s not working either.
if anyone has any ideas about how to debug this, I’d really appreciate the help
the usual cause is that your query doesn’t include the thing you’re changing, so your component’s props are not changing, so the default shouldComponentUpdate is short-circuiting
but there is a “sort of” bug in very recent versions of Fulcro related to
shouldn’t that get fixed by adding the idents of whatever components need to be-re-rendered to the
:refresh within the
transact! call? on latest/3.2.2
wouldn’t refresh with any renderer if you don’t change props…the
:refresh option is a hint: I’d like you to send new props to the things…
when you say “change props”, do you mean not actually changing an entry in the db? because the db is def getting updated properly. the component with the ident at that table location just doesn’t seem to be getting fed the updated data. sorry if I’m misunderstanding here