Fork me on GitHub
#re-frame
<
2019-03-28
>
danielcompton02:03:06

You can create a sub to just return db

danielcompton02:03:26

But we deliberately didn't add an API for that, to encourage you to create several signals

danielcompton02:03:41

Any subscription that needs app-db will run every time app-db updates

danielcompton02:03:11

You can get multiple signals in one subscription, I'd recommend that path personally

mikethompson05:03:36

(reg-sub
   :db
   (fn [db _]
       db))

xfyre11:03:24

I’m trying to find a right approach to React Native animations using re-frame subscriptions. Any pointers? The goal is to improve user experience and UI performance. I expect (please correct me if I’m wrong) that animated changes are going to be more smooth than re-rendering.

danielneal11:03:16

@xfyre animated changes are definitely going to be smoother - if you use the :useNativeDriver option, animations are constructed and sent over the bridge, and from then on can operate smoothly entirely on the ui thread

danielneal11:03:46

I'm not sure I recommend trying to get animations and subscriptions to work together though.

danielneal11:03:39

I sometimes create react animated values and store them in e.g. an atom/registry and then drive them via effects in handlers

xfyre11:03:36

@danieleneal you mean, using Animated.Value?

danielneal11:03:06

normally I'll create these in the mount, and drive them as necessary

danielneal11:03:16

but sometimes I need to access animated values elsewhere, from a different component, so I stick them in a registry

danielneal11:03:09

also animated interpolation is great for reacting to e.g. scroll position

xfyre11:03:47

so this registry effectively acts as an ‘app-db for animated values’, right? and, effectively, this is a kind of ‘alternative subscription’ mechanism specifically for animations?

danielneal11:03:48

you can bind the scroll event to an animated value, and then interpolate it to have things that resize or transform as you scroll

danielneal11:03:58

yeah, you could also put them in the db

danielneal11:03:39

but they're references rather than values, and subscriptions won't work with them so I prefer to keep it separate

xfyre11:03:00

yep, that makes sense. thank you!

xfyre11:03:32

so actually subscriptions can be used to update animated values, and then native animations will take care of the rest

danielneal11:03:57

um I update them in handlers rather than subscriptions

danielneal11:03:10

like often you'll need to call animated.start

danielneal11:03:17

which makes more sense in an event, than in a reactive subscription

danielneal11:03:20

if you see what I mean

xfyre11:03:29

yes, if you need transitions that’s right. my goal is slightly different: imagine a kind of a list where each row displays a certain value and certain state. manipulations with one row may affect state of other rows, as well as displayed values. at the same time values must be stored in app-db because they carry a certain meaning, which later should be submitted to backend (after user has made all adjustments). my initial rough implementation did this via subscriptions, it works as expected, but user experience isn’t smooth (because subscriptions has to re-render many rows simultaneously).

danielneal11:03:06

ahh I see what you mean

danielneal11:03:13

I still prefer keep this kind of thing out of subscriptions as I see it as more view level

danielneal11:03:26

in current react I would put it in a component-did-update method

danielneal11:03:37

in latest react, you could use an effect hook

danielneal11:03:29

so you do react to the new value of subscription

danielneal11:03:37

but kick off an animation when you receive new props

xfyre11:03:02

so the result of user action has to be stored in app-db anyway, but displaying this result should probably be done via alternative mechanism like you suggested

danielneal11:03:59

yep, exactly!

tomaas14:03:18

hi, having something like this: (re-frame/dispatch [::events/a]) (re-frame/dispatch [::events/b]) Is it guaranteed that the handler of event a will be run before the handler of the event b. Both handlers update db

ag23:03:51

Hey friends. I’m trying to find a workaround for a very peculiar issue. I would appreciate any tips and suggestions. This is happening only: - in Mobile Safari (iPhone, iPad) - And on minified source In a re-frame input components (which otherwise work fine in other browsers or unminified source) there’s a noticeable annoyance - characters appear with a jittery lag. And I’m scratching my head what could that be. Either closure compiler borks things up, or mobile safari is doing something stupid

ag00:03:58

update… apparently it is happening in Chrome on iPad too. Android seems to be fine

ag23:03:38

something like this. This is from the simulator. On a real device it’s even worse

lilactown23:03:52

@ag what kind of input are you using?

ag23:03:55

what do you mean? what kind of html input? I think it affect all types :email and :text are the ones I’m seeing it in

lilactown23:03:28

controlled inputs with async rendering is really gross

ag23:03:18

this is a basically the base of the component, disclaimer: this is not my code - I simply inherited it and until today seen no issues with it https://gist.github.com/agzam/0f3b65a156d2869db85f50f22e30b702

lilactown23:03:53

are you using a wrapper for material-ui?

lilactown23:03:04

or the raw React lib

ag23:03:18

[cljsjs/material-ui “3.9.1-0”]

lilactown23:03:48

then you should definitely read the above issue

4
lilactown23:03:54

there’s an example with how to fix it