Fork me on GitHub

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.

Patrick Brown11:07:01

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?


seems good. I wasn’t trying to say it isn’t useful

Jake Murphy14:07:20

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.

Jake Murphy16:07:23

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.