Clojurians Log v2

Hey is there any reason untangled client does not allow you to set :shared and :shared-fn?

@gardnervickers not particularly. we haven’t had a need to customize the reconciler options so we haven’t built it in

what do you want them for?

@ethangracer We have a background process that has the potential to be long running and hold up other mutations, the plan was to stick it in a go-loop and merge-state when it finishes. I wasn’t sure the best place to store a reference to that.

store a reference to what exactly?

some indication that the process finished?

Something like {:process … :input-channel …}

So we can tear it down, and send data to it.

Hm

Oh hmm, I guess :shared wont give me a reconciler though...

nope

the other thing is that anything you put in shared can just as easily be replaced with links

True

That makes more sense

if you have a long running process, is there a way not to put it in a mutation?

A set of mutations to setup/teardown the process and put my reference in the app state.

really their only purpose is to modify app state, and send mutation requests to the server

so if you have a background process on the client that isn’t constantly doing either of those things, it may be better not to run it inside of an om transaction

The background process is a pure function to update the app-db. As users enter text, it needs to be re-run with the most up-to-date data. We want to be able to cancel old runs and start re-processing with the new data.

how is updating the app-db with new text a long process? I think I’m missing something

if it’s easier to describe than type feel free to give me a slack call

Ok yea, so there’s an editor box where a user can type in some text. That’s fine and can be updated inside a regular mutation. However inside that mutation we want to signal to a background process that it should start running on the newly updated text, this long running background process provides a “compiled” version of the text in the editor box for a side window.

At a noisy coffee shop 😕 If I’m still doing a poor job describing this maybe we could chat later.

I think what I don’t understand is why the background process is necessary. Seems like it’s a function that takes text from the editor box, and then does some kind of complex computation on the app state to generate new app state. Then when the computation is done, you want to use merge-state to push those changes back in

So if that function is operating on the app state, which is theoretically pretty small, I’m not grocking why the task takes awhile

maybe we should just chat when you’re not at the coffee shop

sorry I don’t have a more immediate answer, we definitely haven’t encountered this kind of task before

Thanks for your help, I think my problems here are representative of a larger design issue.

Yeah no worries, let me know if it ends up not being a design thing and we can talk about whether / how untangled could change to accomodate

@gardnervickers In general long-running things have two approaches (if you need results in the UI): 1. Submit the mutation, and have it start it up (e.g. include a tempid), then periodically run a follow-up mutation (setTimer) that sends back the tempid and gets a remap on complete. 2. Something similar, but with web sockets for server push back of result

That way your submission cannot block anything, and you manage the complexity on the server for the most part.

Looks like Om alpha44 is out (2 days ago)

I've released Untangled Client 0.5.5 to clojars.