This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-08-16
Channels
- # admin-announcements (2)
- # bangalore-clj (3)
- # beginners (15)
- # boot (303)
- # carry (18)
- # cider (7)
- # cljs-dev (222)
- # cljsrn (103)
- # clojure (196)
- # clojure-czech (2)
- # clojure-russia (69)
- # clojure-spec (21)
- # clojure-uk (48)
- # clojurescript (68)
- # cursive (18)
- # datomic (185)
- # events (1)
- # hoplon (2)
- # lambdaisland (1)
- # leiningen (1)
- # mount (10)
- # off-topic (1)
- # om (14)
- # onyx (154)
- # parinfer (1)
- # pedestal (3)
- # planck (5)
- # protorepl (9)
- # re-frame (17)
- # reagent (27)
- # ring (2)
- # specter (58)
- # test-check (1)
- # testing (7)
- # untangled (59)
- # yada (35)
i thought there was something that crawls links and deletes data that has no links to it
if I merge data {:id 3 :foo {:id 4}} and it's normalized to {:x {3 ..} :y {4 ..} } and then I merge data {:id 3 :foo nil}
e.g. I have a list of users. I run a filter to show those that start with 'A'. Now my database only has links to a subset...do I clean those just because a "GC" runs?
well there's some logic you have to write that is essentially checking if table is not referenced by any links, and seems like i have to write this over and over again for each situation that arises
in my example, each time the search query changes, I empty the search results table?
that is much simpler and more reliable than an automatic GC that you have to program
I mean, I guess you could write some kind of GC of your own...it is a simple algorithm if you make certain assumptions (e.g. no refs means cleanup, which isn't good enough for all apps, but might be ok for yours).
but unless you're worried about killing a javascript VM with data size, I would not even worry about it.
most apps don't have huge data sets, and js can have a pretty darn large memory footprint.
anyway...if you write GC, just transact on the reconciler once every 15 minutes or something.
"So just clean the entire table as part of the query logic" in my example this means in the search mutation, I empty the search-results table first before doing load-action ?
we have been writing pretty large apps, and have not found a need for general GC yet, nor is there a great way to solve it in general, as I said.
Untangled does include logic to stomp on stuff that has disappeared (was queried for, but didn't appear)
As I said: no way to be sure (from a library) that a given row in your database is gone, unless the application can prove it. Just because you don't have a UI ref to a user object doesn't mean it is "gone" in your application (might still be persisted on server).
if you don't need data in more than one place, it is perfectly acceptable to treat it as a blob
well, mutating it gets more complex and less modular...but if it is read-only search result data, who cares
I've got a UI that's not updating after a post-mutate after a data-fetch. Looking at the app-state, the data is there where I expect it to be. When I save a file and the react-key is updated, the data shows up in the right place. Any suggestions where I might look?
@grzm try overriding shouldComponentUpdate to return true — see if that causes the re-render
if it does, then the issue is with om’s implementation of shouldComponentUpdate. we’ve seen the behavior before, isolated one case of it, but it’s possible we haven’t found all of them
@ethangracer: Thanks for the idea. I suspect it's more something in my particular application, and that this is just a symptom of something I've done wrong.
@grzm fair enough, I’ve run into that issue plenty of times. you’ve already verified that the data is showing up in your app state, meaning the network request completed. if the request completed and the data was put in your app-state, then the data fetch called merge!
with your data on the reconciler. Which schedules a re-render through om. So if the re-render isn’t happening, it’s either because you haven’t included a necessary key in the :refresh
parameter to load-data
, or because something’s confusing om’s shouldComponentUpdate