This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-16
Channels
- # beginners (11)
- # boot (21)
- # cider (12)
- # clara (6)
- # cljs-dev (7)
- # cljsjs (1)
- # cljsrn (62)
- # clojure (137)
- # clojure-austin (5)
- # clojure-italy (1)
- # clojure-nl (2)
- # clojure-russia (46)
- # clojure-spec (21)
- # clojure-uk (79)
- # clojurescript (56)
- # clr (1)
- # core-typed (1)
- # css (1)
- # cursive (3)
- # datomic (35)
- # docker (2)
- # emacs (20)
- # garden (3)
- # hoplon (8)
- # incanter (3)
- # jobs (12)
- # mount (5)
- # nginx (1)
- # off-topic (71)
- # om (8)
- # om-next (6)
- # onyx (4)
- # perun (3)
- # proton (2)
- # protorepl (5)
- # re-frame (35)
- # reagent (38)
- # ring (5)
- # ring-swagger (12)
- # rum (35)
- # spacemacs (2)
- # specter (5)
- # test-check (6)
- # yada (52)
@paulspencerwilliams I never used AsyncStorage before but I would use periodic saves. Either automatically through setInterval or use a timeout on app state change
With Realm, I write to Realm through a timeout whenever state changes since my app doesn't have that many updates. With a lot of changes it could make sense to periodically update to make sure nothing gets lost
@paulspencerwilliams We write to AsyncStorage on each update of the db (serializing the db using transit, even though it is not recommended for storage, it is way faster than pr-str
). One could technically write on app pause or close but we’re also a little afraid that those callbacks may not always be called. You’d still have to read directly from the in-memory app-db because since the AsyncStorage is slower than accessing memory and does not have the reactiveness required for re-frame. How fast is it to write/read to realm @dvcrn? And do you still need to keep the app-db atom?
I am not sure to be honest. I am not using it directly on read and still have my state atom. I'm having a lazy-load approach where I fetch the data into the state atom if it isn't there yet on read
I wasn't sure which storage solution is the best and wanted the option to swap it out if needed
> Fast > > Realm’s ease of use doesn’t come at a performance cost. Because of its memory mapping, lazy loading, and custom storage engine, Realm is usually faster than SQLite or AsyncStorage despite offering a rich object-based API. Although we always recommend everyone test their own use-cases, we usually see huge speedups when porting code to Realm. See benchmark results below.
I'm too new to iOS to know whether it's a good idea to directly read from sqlite / asyncstorage 😛
So it would appear that using the state atom as primary, with intermittent writes to AsyncStorage and initial load seem to be the best generic solution. Cheers guys.
(defn my-switch []
(let [value (r/atom false)]
(fn []
[switch {:value @value
:on-value-change #(reset! value %)}])))
Whenever I create a switch
element like this on Android there’s a short flicker before the value of the switch is updated. Does anybody know why this might be so unresponsive?(defn my-time-picker []
(let [time (r/atom (date-time "2016-06-01 17:00"))]
(fn []
[date-picker-ios {:date @time
:on-date-change #(reset! time %)}])))
The same kind of flickering can be experienced with ex. a date picker. I suspect that it has something to do with the animation of toggling back to the previous state of the component before the value is updated, but what would be the correct way of structuring the state of this type of stateful component?@ejelome @pesterhazy about ListView
it’s actually not necessary to convert the ClojureScript data structure to JavaScript in order to pass it to the dataSource
I used to think it is, but actually the React Native ListView is designed to be data structure agnostic
@raspasov I found that out as well
It's just a pointer as far the data source is concerned
(defn list-view-data-source [m] (ReactNative.ListView.DataSource. (cljs.core/clj->js (merge {:rowHasChanged (fn [x y] (not= x y)) :getRowData (fn [data-blob section-id idx] (nth (.-s1 data-blob) idx nil))} m))))
basically provide a :getRowData function that is ClojureScript-specific and get data from the vector (aka data blob) via (nth ...
not converting Cljs -> js -> Cljs really helps with performance (and memory usage!) I found
are you developing https://en.wikipedia.org/wiki/I_Am_Rich app, or something, @raspasov ?
or are you just being realistic about your app's release date
we’re only iOS currently, we advertise on Facebook and we do no specific device targeting, about ~20% of people are on iPhone 6; majority of users are on iPhone 6s generation
for faster clj->js rows conversion in DataSource, I just convert list ids, and later fetch actual row data from edn hash-map by those ids.
yes, same; only diff is I use a vector, but actually the hash-map can be even better now that you’re mentioning it!
(defn clone-with-rows-and-gen-indices [a-list-view-data-source data-v] (.cloneWithRows a-list-view-data-source data-v (clj->js (into [] (range (count data-v))))))
I understand the good intent guys, but see, I only started cljs just this month, hahaha, so I can't comprehend that optimization fu
essentially the problem is that anytime you do (clj->js …) conversion or (js->clj …)