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

Alright

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

(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 %)}])))

@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

yes!

I do something like

(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

esp. on older devices like iPhone 6 and below is very noticeable difference

on newer ones you’d barely tell

older devices like iPhone 6

but I really don't notice it in my iPhone 8

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

@misha haha well

our app is already live 🙂

it has been live for like almost 6 months now (all React Native + ClojureScript)

lmao, funny link XD

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

or newer...

not saying that those 20% are not important, to the contrary

that’s why I mentioned it 🙂

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.

(does not fit every use case, obviously, but is good enough for many)

yes, same; only diff is I use a vector, but actually the hash-map can be even better now that you’re mentioning it!

at the very least, it saves the pain of roundtrip conversion of namespaced keywords

for simplifying a separate (get-in …) lookups or (update-in …) opearations

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

this is how my cloneWithRows looks like

the only cljs->js conv. I do is to generate the indices

by which to lookup

I understand the good intent guys, but see, I only started cljs just this month, hahaha, so I can't comprehend that optimization fu

data-v gets passed in unchanged to the ListView

my only goal was to have 1:1 react native sample to re-natal

@ejelome no worries!

so I can easily digest what's happening XD

essentially the problem is that anytime you do (clj->js …) conversion or (js->clj …)

I even stripped re-frame so I can focus on cljs and reagent

it’s slow...

that’s all

but the good thing is that, I'm realizing that conversion is not always mandatory, like the example you show

yep 🙂 just know it’s there, if you need it later

I spent months without realizing you can do this, so that’s why I mentioned it

and I’ve been doing Clojure for years now

lol

hahaha, that saved me months then, thanks 😛

but in any case thanks @raspasov, good thing I don't have an iPhone 6/s

@ejelome are you trying to do iOS or Android first?

or both?

I don't have a mac, so android is the only choice 😄