This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-15
Channels
- # announcements (1)
- # babashka (81)
- # beginners (48)
- # calva (49)
- # clj-kondo (52)
- # cljdoc (7)
- # cljs-dev (39)
- # clojure (33)
- # clojure-australia (18)
- # clojure-europe (48)
- # clojure-italy (2)
- # clojure-morsels (2)
- # clojure-nl (3)
- # clojure-uk (6)
- # clojurescript (5)
- # community-development (2)
- # conjure (6)
- # cursive (3)
- # data-science (29)
- # datalog (4)
- # datomic (14)
- # events (1)
- # fulcro (1)
- # graphql (18)
- # gratitude (2)
- # helix (11)
- # introduce-yourself (2)
- # java (15)
- # keyboards (2)
- # lsp (6)
- # luminus (4)
- # membrane (32)
- # minecraft (1)
- # missionary (7)
- # nextjournal (2)
- # off-topic (28)
- # portal (28)
- # releases (1)
- # ring (1)
- # shadow-cljs (3)
- # sql (6)
- # xtdb (23)
Just did a long trip down the rabbit hole to really try and understand this and thought I would share thoughts. Main take aways were:
• Having used reagent for the last 6+ years led to a major misconception that React defaulted to compare props, now I understand that Reagent does this by default not react
• Even if you are passing immutable data structures as props you are still creating a new props map
• Deep equals (`=`) will work in this case because values can be equal but identical?
will fail
• The function @lilactown shared works because it checks shallow equality via map entry count and identical?
@lilactown you called all this out but I still needed to bang my head against the wall a bit and work with a team member to make an exhaustive test. One more question, since we are using our own defnc
with a factory component flag we need this custom memo fn right? Meaning, if we were using raw dom tags with prop maps those would work as expected with the default memo comparator?
@jon693 I had to bang my head on it a lot until it sunk in 🙂 glad I was able to help a bit.
> since we are using our own `defnc` with a factory component flag we need this custom memo fn right?
that's right. if you were using defnc
without the :define-factory
feature flag turned on, which means you would create elements out of your components using ($ my-component ,,,)
instead of (my-component ,,,)
, then you would not need the custom factory-props-kvs-identical?
compare I wrote above
If I remember right we needed the factory bit so we could call our components without $.
yup. the reason why memo
is misbehaving here is that ($ my-component {:foo "bar" :baz 123})
turns the map you pass in to a JS object, {"foo": "bar", "baz": 123}
, that React can read and compare with memo.
the factory function doesn't turn the map you pass in, into a JS object. instead, it passes it as a single prop, {"helix/props": {:foo "bar", :baz 123}}
React's memo
by default compares each key in the props object using identical?
. so it will compare the map in the "helix/props"
property between each render, get a different result, and fail the memo check.
using $
the memo check would succeed and it wouldn't bother calling the component.
the factory-props-kvs-identical?
function essentially replicates this logic that React does with the props object, with the nested "helix/props"
map