hi, does anyone have a simple example of read/write to AsyncStorage with reframe? Is there already something on github for this? Much appreciated!

@hoopes I've been using https://github.com/glittershark/core-async-storage

if it's good enough for mr. fikes, it's good enough for me. thanks for the pointer!

Having said that, with re-frame, it might be nice to instead come up with a solution that is based on reg-fx instead.

yeah, i think i will try that

@hoopes If you go down that path, and are inclined, make it available as open source. I'd use it and I suspect so would others. 🙂

will do

@hoopes You could, in the interim, define an effect that glues things to core.async, and then use that to compose with core-async-storage. But I think completely eliminating the use of core.async and building the effect directly against the underlying AsyncStorage is the cleanest. Interim glue code might look like this https://gist.github.com/mfikes/a038523049e35699f7699a1c7ff8a3c4

(This is modeled after https://github.com/Day8/re-frame-http-fx)

this is my first couple days with re-frame, so i GREATLY appreciate the pointer. I was trying to see if dispatching from an effect handler was allowed/non-taboo - thanks a lot for that snippet

Yeah, Day8's code is doing that here 🙂 https://github.com/Day8/re-frame-http-fx/blob/master/src/day8/re_frame/http_fx.cljs#L50-L51

I have this very simple component with a textinput control. For some reason when I set the value property I can't type anything in the field, it resets to bob. Any idea why?

[text-input {:value "bob" :auto-correct false}]

@clojurians558 for text-input the “value” field hardcodes it to not allow change. Check the docs for that. I think there is a “default-value” prop

alright, thanks. I did find the default-value prop earlier but I cant' seem to set it in the Input field of the native-base component. (I've been yak-shaving ^^)

I've been trying to find a floating text input control, native-base library seems to have one.

:auto-correct false also does not work. not sure why.

ignore that, it does work.

I was trying to prevent suggestions. I thought that prop would do that.

@hoopes @mfikes Here's how I'm approaching this at the moment. The obvious fiddly bit is that event handlers in reframe are "points in time" so waiting for promises means dispatching. For the moment I'm accepting that limitation. https://gist.github.com/olivergeorge/9a9d2e1b18e27a0c8c950d64101dd8c4

I'd love feedback. Early days for me.

That looks roughly like what I had in mind @olivergeorge 🙂

Cool. Thanks.

I also have something similar for the js/fetch API, but it is almost too small to make a lib out of it

Maybe enough React Native effects could be lumped together to make a decent lib :thinking_face:

If not a lib then a series of simple articles looking at specific techniques for specific concerns might be useful. You know, something like that guy at fikesfarm does so well 🙂

Love your work by the way. Thanks for all your effort.

@olivergeorge awesome, thanks very much! just for my knowledge, why do you and @mfikes prefer this style over the core-async-storage lib?

If you end up writing a lot of re-frame based code, using its events and subs and effects, it ends up being odd to also then have core.async as another way to have async code in the mix. If instead you define effects, you can at least stick with one programming model.

is the use of promises here not kinda in the same vein as core.async though? or is core.async using a sledgehammer to kill an ant?

Promises is yet another async model. I don't really care so much, but the mixture of all of them bothers me 🙂

For example, let's say you are using https://github.com/Day8/re-frame-async-flow-fx In that case it is a little cleaner if you stick with the re-frame way of doing things and use something like @olivergeorge’s code to persist state

Key thing I aim for is isolating the interop stuff. In this case I'm happy since the promises are isolated in the effect fns and don't end up influeneing how I write my app logic.

The underlying React Native APIs are based on promises. It seems natural to bridge that into the re-frame world via fx

(And not introduce core.async)

+1 for less deps

yeah, ok. i appreciate less-is-more. thanks for the explanation!

Then all of your app logic is in the re-frame style