Fork me on GitHub

Hi, I just git-cloned the Untangled Template and want to play around with it. When I start up my lein repl and type in (go) I get a server running on 3000 but all it says is "Loading" ... I see code for a Login UI but it is not apparent how to activate it.


@sova: You need two REPLs to be running - called 'configurations' in IDEA. One normally called 'Server' and the other 'Figwheel'. Is 'Figwheel' running as well?


Hmm - what I said is more liely true for the tutorial (never used the template), which is probably the recommended place to start playing around.


@cjmurphy I just found another projct on github that was very similar, I got it working using (start-figwheel) as opposed to (go) and I'm looking forward to tinkering. Thanks for your assistance


np. If you only have the Figwheel version going (not (go) as well), then you may have a client side only checkout.


is there a way to trigger a remote re-read after a remote transaction with untangled?


i.e. wait for the remote transaction to complete and return, before triggering the re-read client-side


@danielstockton yes that is default behavior with Untangled


Default behaviour how @mitchelkuijpers? I mean, how do you specify the keys/queries to re-read?


@danielstockton If you fire a mutation and a read in one transaction, then untangled will first run the mutation wait for it to return from remote and then fire the remote read.


"Untangled uses Om to manage the UI, and as such the UI refresh story is Om’s story." I don't believe this is the case with Om, the reads fire immediately once the mutation runs on the client.


Are you talking about with om/transact! ?


Yes, with regards to remote mutations and reads (that was the question right?)


Yep. In my tests, the reads get fired immediately and don't wait for the remote response.


I've been trying to fire empty read transactions in merge to make it happen but no success.


What exactly are you trying to do? Maybe you can give more context? And what are you doing with merge?


The use-case is to fire a login transaction which triggers a remote request and receives a token. I then want to re-read the component query to fetch data that requires authorization.


Since follow-on reads seemed to fire immediately, at the same time as the login transaction, I was trying to trigger another remote re-read in merge somehow


Do you want a local read or a remote read?


remote, but it first needs to receive the token to authenticate


its not good triggering it before login responds with the token


If you use a tempid and and then return the token from the remote mutation under that tempid you can do a transaction with the mutation and the read in one. And then Untangled will wait with the remote call until the mutation returns and it will replace the tempid with the actual token before sending the read to the server


It should really not be necessary to fiddle with merge


(I could still be wrong and misunderstanding something)


I see. I'm actually dealing with a Django API on the backend and haven't really dealt with tempids at all but I'll look into it. Thanks for the tip.


And otherwise there is also a callback when a remote mutation returns


that might even be more interesting


(defmulti post-remote-mutate (fn [state k p] k))

(defmethod post-remote-mutate :default
  [state k p]
  (log/info "Default post remote mutate: ~{k}")


And you give untangled this option:

:mutation-merge post-remote-mutate


Is this not similar to doing it in merge? Untangled implements the post mutate hooks in a custom merge I presume.


I haven't actually made the leap to untangled yet, but I'm trying to understand how things are implemented. I haven't fully got to grips with om so I'm reluctant to add another layer of abstraction on top.


Aha ok, I started the same way.. Until I was completely fed up with fixing all the remote stuff myself


Untangled is a pretty thin layer actually on top of OM. But I get the hesitation. The thing that helped me over the leap was the awesome network plumbing:


I think you could say this is pretty similar to doing it in merge btw


Yes, it seems that untangled just adds some opinion where it's lacking, which is good. I will probably make the switch when I really feel like I understand om and am re-implementing a lot of patterns I see are already in untangled. Honestly, it's still an experiment at this stage, I get the problems that om is trying to solve and am just trying to discover the tricky edges in a real-world app.


Does untangled have a story for file uploads as well, do you know? Or some hooks that make it possible?


No not really I don’t think it fits the whole reads and mutation storty


We actually don’t use the untangled server part btw, so you could start only using the client


Yeah, I didn't think the server part was mandatory


No it definately isn’t. For us honestly it felt awesome moving because we kind of had the same things that untangled fixed but way more ad-hoc. And removing all read functions felt awesome 😛


But I think it is good to first try vanilla that way you appreciate it way more


@sova There are two REPLs required. One to run the client-side build process during dev, and one to run the server for full-stack. (go) starts the SERVER side (not client builds) (start-figwheel) starts figwheel (client builds and hot code push)....only used in dev


I thought the README explained that...if it doesn't that needs fixed


Ah, it only shows it in IntelliJ...the command line stuff only shows the server, so the docs need improved


@danielstockton So, some clarifications: 1. Reads after writes (all remote). Basically we have a built-in mutation called untangled/load that you can mix into your transact!. You can also compose load-action into your mutations. So yes, there is support for that. The dev guide talks about this in great detail. There are also cookbook recipes.


2. Image uploads. We did that via mutations and js API to pull image data into a base64 string


See the image library/crop tool in the untangled-components library


(Note that lib is very alpha...but you can see what you're looking for). The image lib/crop tool are actually pretty close to production ready.


and allow you to plug metadata and image storage in as components


3. The merge plugin is more around dealing with return values. I'd recommend explicit remote reads over return values (because you're messing with global merge when messing with merge). But, Om only makes return values available during merge. A multimethod here makes it pretty safe...still, reads are very clear. You might also look at the untangled-template, which has a simulated login that does exactly that.


You are right that follow-on reads are about UI rendering


Om does add a quoting/remoting story to the query syntax that we ignore in Untangled, since it requires implementing parser emitters in order to make it work. Instead we give you direct load functions, mutation triggers, and composition into mutations


@tony.kay thanks a lot. after a lot of researching i think untangled brings the best synthesis of great ideas so i'd really be happy to see it grow and develop (as well for my own understanding of the code)


@sova You're welcome. On growth: yes, that would be good. I'm not the best at marketing. We're in a relatively small corner of the webdev world. Word of mouth never hurts 😉


untangled-template is no longer a leiningen plugin? To use it now, we just clone and go?


maintaining the lein bit is hard, and not compatible with boot, etc


so there are scripts for renaming things


ah, nice. thanks!




or make rename


Also, if we add something to the template if you're based on a clone (or fork) you might have some success merging in the changes.


fixed a portability issue with bin/ wasn't working with gnu-sed. Pushed to develop.


awesome, thanks


go ahead and merge to master