Clojurians Log v2

@tony.kay All of our problems seem to be fixed awesome

I don't think we have a custom network handler we do simply use make-untangled-network And then we add a request-transform option to add our JWT token

So I think these two diagram illustrate what I'm trying to deal with at the moment. I don't have a View of data and a corresponding Form for editing a single item of the data, but rather the Views ARE Forms... they display phone numbers and they also enable editing them.

In this case, whenever I edit something in PhoneListA, I need to update PhoneListB

@urbank In some places where we have multiple lists that should always contain the same idents, we normalize the list as something like [:phone/list :all].

Where PhoneList then has the ident [:phone/list :all].

:phone/list is then a table in the app-db, with it’s value being a list of idents for [:phone-number/by-id …] or something.

Normalization is the right answer for updating app-state once and having it reflect throughout your UI tree.

@gardnervickers Hm, right. This actually solves a good part of it! Something's still bothering me, but I'm not very sure about the specifics yet.

@mitchelkuijpers Cool. Thanks for the verification. I'll probably cut that as a release now that we have the kinks worked out.

That would be awesome, only thing I noticed is that I have tot set the refresh for idents when using loads

?

you mean loading by ident doesn't cause a refresh of those UI items?

So I have to give load the refresh param when doing a load on a ident

hm. strange. I would have thought Om would have gotten that

Yes, sorry I am on my mobile phone

is this when you load using the reconciler, I'd guess?

Hold on getting my laptop

When i do

(df/load this [:foo/by-id 1] MyComponent)

what is this?

A component without a query

So I guess that is the same as just the reconciler

um...it can't work if this isn't a stateful component or the reconciler

this is a component

I guess it could if it is at least an Om component

Yes

but stateless...

it is just a

(defui Object (render [this] ...)

got it. and we removed the global forced rerender, which is why it changed

Yeah, but I would expect to at least trigger a rerender by ident when you are loading by ident

But maybe that is a wrong assumption

(df/load this [:sale.issue/by-id issue-link-id] LinkedIssue {:refresh [[:sale.issue/by-id issue-link-id]]})

this feels wrong

I had assumed that as well. I thought Om queued the queried stuff, but obviously it doesn't. The model does typically assume you trigger transactions from the thing that is the parent of the stuff that needs to re-render, and you add follow-on reads for the stuff not in that subtree

so, this was probably my misunderstanding

I'll set up the loads by ident to auto-add the ident to the refresh list

That would be awesome, would it be logical to do the same when you specify a target for the load? Or load for example :foo/list

possibly

the problem is people can do non-normalized things

so target might target some tree in the db

I would think that that is a good default unless a refresh prop is given

Ah yeah that would be a problem

(they should not do that btw) 😛

But that is a good case where you don't want it

It wouldn't hurt anything to add an ident made of the first two components of the target to the refresh list. Just might not do anything. I don't think Om would puke on it...I'll have to try

1. kw w/no target -> add load kw to refresh list 2. ident -> add ident to refresh list 3. target has 2+ elements -> add first two components of target as ident in refresh list

I'll code that up and push a snapshot in a bit

Nice that sounds like good defaults

@adambros bug in U.spec: It adds selectors to URIs in devcards for some reason in projects that use it. Some kind of hook is getting installed that should not be

on hot code reload

transact is running on set-active-selectors

@mitchelkuijpers new snapshot is on clojars. It is really well-tested, so I may just push a release.

Awesome will test it out tomorrow

Hey folks! While there is a tx/fallback for a server mutation causing an error, is there an equivalent for a successful server mutation? I know that kinda goes against the grain of optimistic updates, but the only thing I can think of would be attaching my successful mutation handler to the :post-mutation handler of a transaction that loaded the resource again.

yes

there is a :mutation-merge option on client

it can transform app state. cannot trigger more remoting, but otherwise should work

set it up, for example, with a multimethod that dispatches on the second arg (the mutation sym)

then you can put your post-mutation handling next to your regular mutation handlingon the client

if what you want it remoting, then you're better off composing a remote-follow-on read into the tx itself (e.g. (transact! this ` [(mutation) (untangled/load ~params)])

argh,...quoting

Ah interesting thank you.

Untangled Client 0.8.1 released to clojars. Fixes some load marker issues, adds support for parallel networking (used by file upload stuff in untangled-ui), removes hard dep on devcards.

@emilyseibert Hey Emily! Glad to see you!

hey! working on ramping up on untangled this evening. super excited to show it off to WillowTree!

Sweet. Let me know if you need any help. The getting started youtube videos are possibly easiest for getting your hands dirty. Then there's a whiteboard video as well on loading data and such.

https://www.youtube.com/playlist?list=PLVi9lDx-4C_T_gsmBQ_2gztvk6h_Usw6R

Some of the stuff, like adding server components video, has better options now if you need to customize the server. The in-the-large videos also led to API expansion in the lib, just FYI (e.g. UI routing is now in devguide)

it was good talking to you at clj-west. Thanks for dropping by!

@tony.kay Should server exceptions on mutations be causing a Root re-render?

um. should, or is it programmed to ?

😉

I am guessing it will only re-render what the mutation would have re-rendered.

but, now that you mention it, it might be a good idea

Heh I wasn’t sure if there was a reason that a mutation down in the tree that failed on the server caused the entire app to re-render from Root

Even if we’re not catching it with tx/fallback

I'd have to look at the fallback logic...don't have it memorized

No worries, thanks!

I can hunt it down

They run outside of the transaction system (since they're in the network layer)

impl.data-fetch

https://github.com/untangled-web/untangled-client/blob/develop/src/untangled/client/impl/data_fetch.cljc#L455

Could augment https://github.com/untangled-web/untangled-client/blob/develop/src/untangled/client/impl/data_fetch.cljc#L466 with an or to get what you want

in fact, that should have been there...we even have an atom for tracking it 😕

yeah, which it was in commit 37db9fca55a11a30f

I think our issue is with items here https://github.com/untangled-web/untangled-client/blob/develop/src/untangled/client/impl/data_fetch.cljc#L445

got lost in an optimization

no, that line looks fine to me. Refresh everything you've asked refresh

that is the correct happy path behavior

oh wait. that is ran-mutations, not fallbacks

nvm...I was looking at loaded, not error

@ran-fallbacks just needs to be in the root rerender logic

@gardnervickers Fixed. On 0.8.2-SNAPSHOT on clojars

oh wait...upload failed...

ok...it is there now

Cool, so that will stop force rendering from root on fallbacks?

oh, no...that will MAKE it force root re-render if there is a fallback on error

Or server error I should say

I mean, we could argue that an error should always force a root re-render, since the fallback could have modified anything anywhere to deal with the error

what say you?

fallbacks only run on server errors. They can do whatever they like to app state. They happen infrequently. As I think about it, I think root re-render is better in all cases

@tony.kay We’re in a situation where we’re creating an entity inside a modal, and the server is rejecting the write. This is causing the page to remount, and the modal flickers.

shouldn't flicker...DOM diff should do nothing if it didn't change

unless you already dismissed it (refresh would hide it) and re-show it on error.

Yeah, I’m not sure what’s up. We’re not changing anything in the DOM there. Trying to hunt it down.

oh...I guess the react key change could possibly cause that

forced root render leads to root render, which changes the react key, which rewrites the entire DOM

Yeah.

but that is a dev-mode concern (the key change).

I think you want the root re-render, but not the key change

I’m not sure if that’s the root cause here. I’ll let you know.

take react-key off of root

@tony.kay You got it

Why does the key change in dev mode? I wasn’t aware of that behavior.

so that if you hot code reloaded a UI change, but the state didn't change, then Om would optimize away the re-render

the :key on root is for that, and ONLY that

Ahh, that makes sense. Thanks for helping me track that down.

you don't want/need it in production

you might even have a ProductionRoot and DevRoot

Then your production mount in main.cljs could be diff than dev mount in user.cljs for example

@tony.kay That’s sensible. Thank you 🙂

welcome

@michaeldrogalis @gardnervickers 0.8.2-SNAPSHOT. I changed it to always rerender from root, but NOT change the react key

so that should eliminate the flicker without needing to worry about the react-key

both of those callbacks essentially should be avoiding touching the react key. If no data changed, nothing should re-render...and Om already handles that

on clojars

@tony.kay Cool, thank you!

I'll make a similar change for loading as well

happy path

pushed that just now...so neither should flicker