This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-07-08
Channels
- # announcements (2)
- # babashka (100)
- # beginners (25)
- # biff (7)
- # calva (13)
- # cider (24)
- # clj-kondo (39)
- # cljsrn (2)
- # clojure (22)
- # clojure-dev (13)
- # clojure-europe (12)
- # clojure-gamedev (3)
- # clojure-losangeles (2)
- # clojure-nl (1)
- # clojure-norway (3)
- # clojure-spec (11)
- # clojure-uk (2)
- # clojurescript (20)
- # core-async (8)
- # cursive (7)
- # data-science (2)
- # datomic (14)
- # emacs (6)
- # events (7)
- # fulcro (9)
- # honeysql (1)
- # kaocha (24)
- # lambdaisland (3)
- # leiningen (6)
- # lsp (30)
- # membrane (7)
- # missionary (10)
- # nbb (48)
- # nextjournal (13)
- # off-topic (6)
- # parinfer (4)
- # pathom (1)
- # polylith (1)
- # reagent (7)
- # rewrite-clj (6)
- # ring (11)
- # sci (7)
- # shadow-cljs (8)
- # sql (13)
More of a conceptual question here - why are pre-merge
and initial-state
not the same function? I fully understand that they are different, and that initial state generally seeds the state tree and pre-merge generally re-shapes the tree when normalizing it, but those two things seem very related. Often, pre-merge
is more powerful, but the way I’ve used it in the past usually doesn’t touch the features available. If anything, my average pre-merge
usage could be implemented (and would be nicer implemented) as (comp/get-initial-state ComponentBeingMerged data-being-merged)
. A little bit of a ramble, but hopefully the question makes sense.
pre-merge is an active concern. Initial state is not. Pre-merge has much more to do with real I/O and live changes. Initial state is just your first-frame data. The former needs input (the data to BE merged that is to be munged) whereas the latter is a provider of data for just the initial db.
I rarely use pre-merge. It’s a contributed feature that has some nice aspects, but I personally prefer to put that logic in a UISM or mutation. But, if you don’t have a logic system around your components and are just using load, then pre-merge is kinda nice.
I’m using pre-merge pretty heavily to add updates to time-series data. Say, I’m making two remote calls for overlapping data, I’m doing the logic to ensure that I overwrite updated data points without clobbering the existing data when it’s merged, ending up with a larger map that contains all keys needed in the UI. This all occurs inside a single pre-merge function. TX data looks something like this.
[{:t-1 #inst 1 :key-a 10 :key-b 23}
; ...
{:t-100 #inst 100 :key-a 34 :key-b 12}]
[{:t-20 #inst 20 :key-a 55 :key-x true}
; ...
{:t-60 #inst 60 :key-a 11 :key-x false}]
Is this the correct use of pre-merge? I thought I was pretty smart, but… maybe I’m cutting steak with a fork here. Thoughts?
How can I setup the remote to query a different endpoint than the js origin? I'm developing and figwheel is serving index.html from localhost:4000 and a server is listening on localhost:3000 where I would like to respond to api requests. I have tried passing :url param to com.fulcrologic.fulcro.networking.http-remote/fulcro-http-remote, however, this is simply appended to the js origin (localhost:4000/localhost:3000/api). I have also tried adding a :request-middleware param which changes the url in the request object, however, this also is simply appended to the js origin. Must I write my own remote implementation? Seems a bit much...
:url
of fulcro-http-remote
should set it, not append it. You sure you’re sending what you think you’re sending?
If you look at the implementation, it does NOT combine the url
with anything at all internally.
Well that's weird. Earlier I was seeing http://localhost:4000/localhost:3000 in chrome's networking records, but I don't know how because it is working as you describe now (setting the url). Sorry about that, I'm just getting into looking up docs and source with emacs... lots to learn. Thank you.