Fork me on GitHub

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.


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


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


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.