This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-04-17
Channels
- # 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)
- # cursive (2)
- # datomic (10)
- # 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)
- # xtdb (33)
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?
I think he talks about the math namespace there, and discusses using Transit
I think I found it: https://youtu.be/F7QzFpo8pA0?t=965 nevermind
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
https://www.apollographql.com/docs/react/caching/cache-configuration/#data-normalization
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 transact!!
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
The process is DB -query-> data tree -> props. You have already mentioned that the DB is updated properly so what else could be "wrong" is the query of B/C not asking for the changed data.