Fork me on GitHub
#untangled
<
2017-04-05
>
mitchelkuijpers10:04:43

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

mitchelkuijpers10:04:53

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

urbank11:04:33

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.

urbank11:04:57

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

gardnervickers11:04:45

@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].

gardnervickers11:04:18

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

gardnervickers11:04:34

: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.

gardnervickers11:04:45

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

urbank11:04:56

@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.

tony.kay15:04:49

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

mitchelkuijpers15:04:00

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

tony.kay15:04:43

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

mitchelkuijpers15:04:49

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

tony.kay15:04:06

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

mitchelkuijpers15:04:14

Yes, sorry I am on my mobile phone

tony.kay15:04:40

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

mitchelkuijpers15:04:02

Hold on getting my laptop

mitchelkuijpers15:04:51

When i do

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

tony.kay15:04:00

what is this?

mitchelkuijpers15:04:13

A component without a query

mitchelkuijpers15:04:21

So I guess that is the same as just the reconciler

tony.kay15:04:45

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

mitchelkuijpers15:04:09

this is a component

tony.kay15:04:11

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

tony.kay15:04:16

but stateless...

mitchelkuijpers15:04:44

it is just a

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

tony.kay15:04:26

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

mitchelkuijpers15:04:47

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

mitchelkuijpers15:04:53

But maybe that is a wrong assumption

mitchelkuijpers15:04:31

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

mitchelkuijpers15:04:34

this feels wrong

tony.kay15:04:30

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

tony.kay15:04:39

so, this was probably my misunderstanding

tony.kay15:04:53

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

mitchelkuijpers15:04:48

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

tony.kay15:04:30

the problem is people can do non-normalized things

tony.kay15:04:38

so target might target some tree in the db

mitchelkuijpers15:04:42

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

mitchelkuijpers15:04:52

Ah yeah that would be a problem

mitchelkuijpers15:04:14

(they should not do that btw) 😛

mitchelkuijpers15:04:27

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

tony.kay15:04:48

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

tony.kay15:04:58

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

tony.kay15:04:56

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

mitchelkuijpers15:04:38

Nice that sounds like good defaults

tony.kay16:04:55

@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

tony.kay16:04:11

on hot code reload

tony.kay16:04:46

transact is running on set-active-selectors

tony.kay16:04:42

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

mitchelkuijpers16:04:42

Awesome will test it out tomorrow

gardnervickers16:04:08

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.

tony.kay16:04:32

there is a :mutation-merge option on client

tony.kay16:04:19

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

tony.kay16:04:21

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

tony.kay16:04:41

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

tony.kay16:04:40

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)])

tony.kay16:04:05

argh,...quoting

gardnervickers17:04:13

Ah interesting thank you.

tony.kay17:04:54

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.

tony.kay17:04:38

@emilyseibert Hey Emily! Glad to see you!

emilyseibert17:04:54

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

tony.kay17:04:54

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.

tony.kay17:04:25

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)

tony.kay17:04:08

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

gardnervickers18:04:45

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

tony.kay18:04:08

um. should, or is it programmed to ?

tony.kay18:04:35

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

tony.kay18:04:47

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

gardnervickers18:04:13

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

gardnervickers18:04:29

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

tony.kay18:04:59

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

gardnervickers18:04:16

No worries, thanks!

gardnervickers18:04:22

I can hunt it down

tony.kay18:04:59

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

tony.kay18:04:20

impl.data-fetch

tony.kay18:04:38

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

tony.kay18:04:23

yeah, which it was in commit 37db9fca55a11a30f

tony.kay18:04:40

got lost in an optimization

tony.kay18:04:13

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

tony.kay18:04:22

that is the correct happy path behavior

tony.kay18:04:04

oh wait. that is ran-mutations, not fallbacks

tony.kay18:04:13

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

tony.kay18:04:35

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

tony.kay18:04:14

@gardnervickers Fixed. On 0.8.2-SNAPSHOT on clojars

tony.kay18:04:24

oh wait...upload failed...

tony.kay18:04:59

ok...it is there now

gardnervickers18:04:29

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

tony.kay18:04:49

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

gardnervickers18:04:51

Or server error I should say

tony.kay18:04:31

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

tony.kay18:04:14

what say you?

tony.kay18:04:06

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

michaeldrogalis18:04:19

@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.

tony.kay18:04:49

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

tony.kay18:04:07

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

michaeldrogalis18:04:36

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

tony.kay18:04:37

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

tony.kay18:04:57

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

tony.kay18:04:26

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

tony.kay18:04:47

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

michaeldrogalis18:04:00

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

tony.kay18:04:59

take react-key off of root

michaeldrogalis18:04:25

@tony.kay You got it

michaeldrogalis18:04:45

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

tony.kay18:04:06

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

tony.kay18:04:19

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

michaeldrogalis18:04:26

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

tony.kay18:04:27

you don't want/need it in production

tony.kay18:04:48

you might even have a ProductionRoot and DevRoot

tony.kay18:04:09

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

michaeldrogalis18:04:30

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

tony.kay20:04:24

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

tony.kay20:04:07

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

tony.kay20:04:51

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

michaeldrogalis20:04:57

@tony.kay Cool, thank you!

tony.kay20:04:13

I'll make a similar change for loading as well

tony.kay20:04:23

pushed that just now...so neither should flicker