This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-01-31
Channels
- # announcements (22)
- # asami (19)
- # aws-lambda (4)
- # babashka (42)
- # beginners (43)
- # calva (28)
- # cider (1)
- # clerk (79)
- # clj-kondo (12)
- # clojure (47)
- # clojure-berlin (1)
- # clojure-brasil (1)
- # clojure-dev (12)
- # clojure-europe (40)
- # clojure-nl (2)
- # clojure-norway (5)
- # clojure-uk (3)
- # clojurescript (56)
- # clr (12)
- # conjure (8)
- # cursive (4)
- # datomic (78)
- # dev-tooling (6)
- # exercism (1)
- # fulcro (9)
- # hoplon (3)
- # jobs (3)
- # jobs-discuss (4)
- # lambdaisland (3)
- # leiningen (1)
- # london-clojurians (1)
- # lsp (125)
- # malli (32)
- # matcher-combinators (3)
- # nrepl (1)
- # off-topic (6)
- # pathom (39)
- # re-frame (13)
- # releases (2)
- # remote-jobs (3)
- # sci (7)
- # shadow-cljs (117)
- # sql (6)
- # squint (7)
- # tools-build (15)
- # tools-deps (12)
Given that 3.6.0 is out with official support for React 18, could somebody give a quick rundown on how does the new system work, since contexts weren't needed after all? And also, are there any benefits with fulcro, apart from future proofing when the legacy support goes away?
At least ident-optimized render is now deprecated, but I'm not sure is it simply because it won't work, or is the react 18's async mode just better too.
Staying current with the ecosystem was the main drive. Access to the wider array of js libraries for prewritten UI components seems very important to me.
Ident-optimized render has never been faster in my measurements, and just complicated application code. I really left it in for bw compat and as a curiosity. It may actually continue to work fine. I’m just stating my intention to no longer maintain it. Contributors can easily copy the existing code and patch if they want. The async rendering support of React may or may not affect it. I suspect it should work.
I realized that context wasn’t necessary (and was adding significant overhead). I’m copying the dynvars at strategic points so they are actually available in the low-level react props at any time (so that render can re-establish them). This was actually always the design, and with some minor tweaks and fixes continued to work fine. Using context for the same thing added a ton of garbage to the tree because one of the things I track is parent
, which changes constantly.
There are some new hooks that might be useful in React 18. I’m personally only interested in ecosystem compatibility for my own apps at the moment.
I suppose Suspense and Transitions won't be really useful in Fulcro proper. Hard to see the use, when data fetches are not done in the components, and in any case there are already routers to handle cases where the component is loading
I haven’t really thought about it much, but on the surface I’m not seeing any distinct advantage there. The fact that React can interrupt rendering to respond to a user event is a possible improvement.
But yeah, the idea that components should be integrating that tightly with I/O is “convenient” but I see it as encouraging poor coupling.
Perhaps in some reusability cases it might make sense. Like importing a single sign on button, and just give the id as prop and it can handle all the needed I/O