Clojurians Log v2

@adambros @mitchelkuijpers we haven't implemented access to Om shared because in several discussions with people on the channel we have always arrived at design alternatives that were easier to reason about

@ethangracer Yeah I also came tot that conclusion by just using a few globals and global atoms

How does the loading marker work when you load a collection? I cannot seem to get a hold of it

@mitchelkuijpers you can add [:ui/loading-data ‘_] to the query of any component whose query composes to root. It’s a boolean value set to true when a data fetch is in progress

Yeah, I know but I want to know if a certain query is running

ah, gotcha

But I noticed something strange, it won’t add the loading indicator when i add params

and it adds nil nil in the app state

we knew about the nil nil, not sure we caught the loading indicator too

https://github.com/untangled-web/untangled-client/issues/22

Yeah I saw the nil nil in the issues

the loading indicator should show up in the location in app-state where the data will be placed

if it isn’t, then you should file a bug

Yeah, it only does when I remove the params

weird

The two are probably related

yeah definitely throw a minimal repro up as a github issue and I’ll take a look

Sure

Thnx

yeah, thank you

@ethangracer https://github.com/untangled-web/untangled-client/issues/32 Very easy to reproduce ^^

@mitchelkuijpers interesting, even when :marker is set to false?

if :marker is false there should never be a ui fetch state

right?

yeah, if :marker is not specified, it defaults to true

cool, I’ll play around. thanks

Thnx man

@mitchelkuijpers I pulled down your repo and am trying to run it, but there don’t appear to be any html files in the resources folder… ?

Ow lol

Hold on

k

Pushed

thanks

@mitchelkuijpers you’re right, they are related

There’s a bug in untangled.client.impl.data-fetch/data-query-key where it returns nil on a parameterized query. So a load marker is put under key nil and cleared out once the load is completed.

Aha that explains the nil key

which is also why the load marker isn’t in the right place

yup

two birds one stone 🙂

Nice

Would you like me to submit a pull request?

I would be happy to fix it

Thanks for offering, should be pretty quick I have this one

Cool

I think you might be fixing 3 issues

https://github.com/untangled-web/untangled-client/issues/24

this one is also related?

haha yup

I think I got that one

We’ll this will be a good fix then, i liked them to the issue for you

the logic in those files could use some serious code tuning

@tony.kay another project during documentation week, perhaps, would be to explore simplification of the data fetch logic

@mitchelkuijpers thanks for linking

No problemo, happy to help. If you guys ever have some small things that needs fixing but no time be sure to give me a heads up. Would love to contribute some work back

awesome! that’s much appreciated

just writing some tests and I’ll send it up to github. we’ll have to wait for tony for a snapshot update

Cool thnx

@ethangracer hit me with a PR on that pls

will do

untangled spec is giving me a hard time for some reason

😕

I can’t get the tests to run so I’m going to submit the patch as a PR

I’ll fix the testing when I refactor

commented out at the moment and manually tested?

Is there a way to just unmount an untangled app and mount it again? Our om.next solution was add-root! and remove-root! I am integrating with a bigger application and I am having a hard time changing the root dom-node

you can use Om's remove-root!...it is an Om app

the new reset stuff might be needed for remounting...have not tried it

https://github.com/untangled-web/untangled-client/pull/33

Something appears to be broken with our Travis CI build

not running the tests

travis Firefox is kinda flaky...sometimes fails for bad reasons like timeouts

0.5.7-SNAPSHOT is on clojars of client. Should fix a number of load marker bugs

@mitchelkuijpers I would recommend that you avoid loads triggered from component mount, since React can do mount/unmount at unexpected times

You're better off doing the loads from the operation that led to your UI change that leads to the mount of that component

that way arbitrary UI changes that lead React to think one thing is going away and another is coming in (where in fact they are the same thing) won't cause subtle bugs

If anyone knows how to get Travis CI to do a better job of running tests through Firefox, let me know. Our tests pass, but when Travis runs Firefox it often times out and counts all tests as failing

Yeah I don't do that. This was only a small playground

Thanks for the snapshot!

let's say in the UI the user can 'update the status of object ID <id> to <NEW_STATUS>' in the backend this is idempotent, it tries to succeed regardless in a number of scenarios e.g. (1) status is updated (2) status was already set to new status (3) it did some workaround in an error case, and I want feedback into the UI about which path it took to succeed

is this a load field action + api-read ?

since there's data flowing from server to client

(the feedback)

Btw is it possible to get the result of a remote mutation (the response?)

@ethangracer I can confirm that the fix works 🙂 thank you so much

woohoo!

your welcome. glad you’re enjoying untangled so far

Yeah I am currently deleting all of my om.next reads

loads of fun

@mitchelkuijpers i dont think we let you access the response of a mutation, but there is technically a untangled.client.mutations/post-mutate that gets called after a mutation’s :action https://github.com/untangled-web/untangled-client/blob/b5b1106ae89470651c040af3469652f6033f1b8c/src/untangled/client/impl/om_plumbing.cljs#L38

what are you wanting the result of a mutation for?

I am porting some code where we add something to a list and then clientside we have to call a method to update a counter, so that mutation returns the data we need to calculate that counter (we need to do this client-side, because of reason with atlassian-connect integration)

But maybe we should just add a new read to get that information

yeah you could either figure out how to make the response available, or you just need to add a level of indirection and have a server side counter

then you could just [(inc-counter) :counter]

Haha i know the escaping of mutations 😉

are you talking directly to atlassian? haha yeah i couldnt figure it out

Yes

hmm well then im not sure what your best option is, but i can tell you that you’d be poking around here: https://github.com/untangled-web/untangled-client/blob/26c1844958433dbcee0838a5521fb1885b485a3e/src/untangled/client/core.cljs#L104 and making the :response-channel optionally pluggable

either cb, a multimethod or something

I could fix this with a read so I might try that

try that, but it could be useful to have a story for mutating non untangled-server api’s and wanting the response

I think ill just do an optimistic update 🙂

hehe yeah that too

then I can just revert when necessary

But still it might be usefull indeed

I expected that the post-mutation would have it

we’ll be having a documentation/refactoring iteration in a week or two, so i could take care of that easily/quickly if you need it

hell i could do it now if you really need it

I can wait I’ll change it to an optimistic update (I find that a nice solution)

But it would be a nice improvement

Do you want me to create an issue?

i think tony may be of the opinion you should normally be doing an optimistic update followed by reads

but feel free to make one and we can discuss this there

Sure thnx

@adambros @mitchelkuijpers the intended design pattern is to do the remote mutation followed immediately by a remote fetch

e.g [(remote/mutation) (untangled/load-data query)]

mutations only return tempids

right, but how does it work if you talk directly to a non-untangled server?

esp one that you dont control

wouldn’t that just be a standard http post?

I suppose you could build a custom untangled networking object

if i think about it @mitchelkuijpers must have an untangled-server, so i dont know what he meant by he talks directly to atlassian

i suppose, but what if you also have an untangled server?

yeah you’d have to have something like multiple om remotes

yeah, which we dont support yet

anyway i think the recommended route is to have an untangled server communicate with these other services

For another data-point, I'm using untangled-client with my own (pedestal-based) server. It's working fine. I just make sure I return the tempid mapping.

@adambros @mitchelkuijpers @ethangracer Ethan is correct here. The Om model is that mutations can remap tempids. There is no return value. The reason for this is that there is no query, so there is no way to merge that result into your database. Thus, the follow-on remote read

This is a common misconception about the overall model

The model is that the mutation is abstract. The UI and Server have no coupling. The server has no idea what you're showing, and the client has little idea (other than advertised keywords on the mutation...which isn't documented well, but is part of Om) what the server is really doing.

So, in order to fix this gap, the client specifically asks for reads on the data that it knows it is displaying that could have changed on the server

The mutation would have to "cover the bases" to ahve a return value (and it would have to have a normalization query)

E.g.

Say you have a mutation add-friend. The server could return all manner of information: the new friend count, a success code, the list of current friends

Now you're tempted to make a mutaiton for every possible return value? Or just send it all back?

None of that is nearly as simple as the UI directly saying: do this, and then I need to know this other thing

If you read the Om docs David mentions listing keys on a mutation. These are where you put advisory documentation on your mutation as to what data items the mutation affects, so that a UI programmer can read that (as documentation) and decide what to explicitly query

I'd recommend documenting the affected keys in whatever way makes sense for your developers, because this is a point of difficulty (and maintenance), though in practical systems it is pretty obvious what things you might want to read because the mutation is an abstraction with general meaning.

E.g. in the add-friend case I can guess that my friend count just changed.

It is a subtle shift, and I understand the desire to want a "return value"...but they just don't make sense in the overall model

(and I'd argue that David is right here...this is a simpler/better approach to the problem of UI composition)

I really need to write this all down in a Blog entry or something 😄

I think that explanation helped me a lot - a blog post about the model would be great. 🙂

oh boy...yeah, sounds like I really need to do it if you've written a complete commercial app and you're just getting it 😜

Heh, yeah - I generally understand that mutations don't return anything, but I've never really tied together the reasoning behind it is specifically "you don't know what to return because that's what reads are for"