This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-05
Channels
- # architecture (2)
- # aws (1)
- # bangalore-clj (4)
- # beginners (97)
- # boot (35)
- # cider (8)
- # cljsjs (3)
- # cljsrn (35)
- # clojure (190)
- # clojure-dusseldorf (4)
- # clojure-italy (7)
- # clojure-poland (1)
- # clojure-russia (17)
- # clojure-spec (74)
- # clojure-uk (30)
- # clojureremote (2)
- # clojurescript (298)
- # code-reviews (18)
- # component (18)
- # cursive (18)
- # datascript (3)
- # datavis (2)
- # datomic (24)
- # dirac (17)
- # emacs (3)
- # garden (7)
- # hoplon (51)
- # jobs (2)
- # jobs-rus (2)
- # leiningen (4)
- # luminus (11)
- # mount (24)
- # off-topic (1)
- # om (32)
- # onyx (25)
- # pedestal (1)
- # powderkeg (9)
- # protorepl (6)
- # re-frame (11)
- # reagent (15)
- # spacemacs (6)
- # sql (35)
- # uncomplicate (1)
- # unrepl (74)
- # untangled (130)
- # yada (6)
@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.
@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
So I have to give load the refresh param when doing a load on a ident
Yes, sorry I am on my mobile phone
Hold on getting my laptop
When i do
(df/load this [:foo/by-id 1] MyComponent)
A component without a query
So I guess that is the same as just the reconciler
this is a component
it is just a
(defui Object (render [this] ...)
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
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
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
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
@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.
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)])
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.
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.kay Should server exceptions on mutations be causing a Root re-render?
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
No worries, thanks!
I can hunt it down
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
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
@gardnervickers Fixed. On 0.8.2-SNAPSHOT on clojars
Cool, so that will stop force rendering from root on fallbacks?
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
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.
Yeah, I’m not sure what’s up. We’re not changing anything in the DOM there. Trying to hunt it down.
forced root render leads to root render, which changes the react key, which rewrites the entire DOM
I’m not sure if that’s the root cause here. I’ll let you know.
@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
Ahh, that makes sense. Thanks for helping me track that down.
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 🙂
@michaeldrogalis @gardnervickers 0.8.2-SNAPSHOT. I changed it to always rerender from root, but NOT change 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
@tony.kay Cool, thank you!