This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-03-28
Channels
- # aleph (48)
- # announcements (3)
- # bangalore-clj (1)
- # beginners (131)
- # cider (30)
- # cljdoc (6)
- # cljs-dev (53)
- # cljsrn (24)
- # clojure (312)
- # clojure-austin (2)
- # clojure-europe (4)
- # clojure-finland (6)
- # clojure-nl (24)
- # clojure-spec (24)
- # clojure-uk (66)
- # clojurescript (185)
- # core-async (46)
- # cursive (10)
- # data-science (9)
- # datomic (15)
- # devcards (2)
- # emacs (50)
- # fulcro (28)
- # jobs (1)
- # jobs-discuss (2)
- # kaocha (11)
- # lein-figwheel (12)
- # nyc (1)
- # off-topic (105)
- # other-languages (80)
- # pedestal (6)
- # re-frame (50)
- # reagent (5)
- # reitit (1)
- # remote-jobs (2)
- # ring (10)
- # rum (1)
- # shadow-cljs (10)
- # spacemacs (19)
You can create a sub to just return db
But we deliberately didn't add an API for that, to encourage you to create several signals
Any subscription that needs app-db will run every time app-db updates
You can get multiple signals in one subscription, I'd recommend that path personally
(reg-sub
:db
(fn [db _]
db))
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.
@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
I'm not sure I recommend trying to get animations and subscriptions to work together though.
I sometimes create react animated values and store them in e.g. an atom/registry and then drive them via effects in handlers
@danieleneal you mean, using Animated.Value?
normally I'll create these in the mount, and drive them as necessary
but sometimes I need to access animated values elsewhere, from a different component, so I stick them in a registry
also animated interpolation is great for reacting to e.g. scroll position
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?
you can bind the scroll event to an animated value, and then interpolate it to have things that resize or transform as you scroll
yeah, you could also put them in the db
but they're references rather than values, and subscriptions won't work with them so I prefer to keep it separate
good luck!
so actually subscriptions can be used to update animated values, and then native animations will take care of the rest
um I update them in handlers rather than subscriptions
like often you'll need to call animated.start
which makes more sense in an event, than in a reactive subscription
if you see what I mean
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).
ahh I see what you mean
I still prefer keep this kind of thing out of subscriptions as I see it as more view level
in current react I would put it in a component-did-update method
in latest react, you could use an effect hook
so you do react to the new value of subscription
but kick off an animation when you receive new props
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
yep, exactly!
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
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
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
this react control: https://material-ui.com/demos/text-fields/
https://github.com/reagent-project/reagent/issues/265 is probably relevant
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