@rukor yea I've dealt with this as well

(test 123)

(defn set-input-text! [component k s] (let [refs-m (js->clj (.-refs component) :keywordize-keys true) c (get refs-m k)] (when c (.setNativeProps c (clj->js {:text s}))))) (defn default-on-change-text ([new-text ks] (default-on-change-text new-text ks identity)) ([new-text ks value-f] (default-on-change-text new-text ks value-f nil)) ([new-text ks value-f ref-id] (fn [c] (let [new-value (value-f new-text)] ;set native props (when (keyword? ref-id) (set-input-text! c ref-id new-value)) (om/update-state! c (fn [old-state] (assoc-in old-state ks new-value)))))))

damn it slack how do I do this lol

but yea that's the code... using om-next but the only thing you'd have to change is om/update-state! to whatever your favorite library does to change local state

bottom line: (.setNativeProps ...) was the magic I found

@raspasov use triple backticks before and after string to code-quote

easier than markdown actually, it doesn't even have to be in a new line

@raspasov that snippet's for avoiding input lag, correct?

can you elaborate a bit how that works so I can port it to reagent?

@pesterhazy: I think he is forcing the props to change immediately while waiting for the whole app state to change

@pesterhazy looking at what I did here, I'm not sure it's the best idea, it's a little bit of a lie; I'm directly and mutably setting the native prep (via .SetNativeProps) AND saving the most recent input value into local state

the real reason for that is because I already had the code that was collecting/grabbing from local state

and I didn't want to re-write that when I discovered towards the end that there's no other way to make it lag-free

except for setting the native prop mutably

@levitanong yes and I'm actually NOT driving the value of the input field with local or any state at all

it's just directly being set on every tap/keystroke

I could not get it lag-free with anything else

It's definitely better than how I've been doing it.

so like here...

(text-input {:style        text-input-style
                               :autoCorrect  false
                               :editable     false
                               :maxLength    5
                               :ref          "input-billing-zip"
                               :onChangeText (fn [new-text] (put! comm-ch (u/default-on-change-text new-text [:form-data ::specs-next/zip])))
                               :keyboardType "number-pad"
                               :placeholder  "Billing Zip"})

Interesting. You're running a spec to validate the input?

yes

works great for that!

but I run it on "Submit" press

Ah, I was wondering why there was no callback for when the spec complains

ah yea : )

you could probably run it on every tap of you wanted to, *probably* won't be an issue but haven't tried it

As a side note: Have you been running into performance issues on om.next? I'm using it too, and it's starting to bog down. :(

generally, no

just fyi, my experience is iOS only

Ditto

what generation phones are you targeting? and what specifically are you trying to achieve

Well, navigatorExperimental uses the JavaScript thread so I'm not that surprised

iPad Air

yea... I'm not using that... (nav xp)

Haha I'm also thinking of switching back to navigatorios

iPad Air? what phone is that similar to?

Hmmm lemme check

so I've tried everything down to iPhone 5

It uses the A8X chip. Recent generation. Definitely more powerful than the iPhone 5.

our apps runs very smooth on iPhone 6s, 7, reasonable on iPhone 6, and passable on iPhone 5

Have you been using navigatorios, or just navigator?

none of that

Oh!

ScrollView

ListView

View

Image

keeping it simple : )

+ a few libraries of course

like BlurView

Ah, well it's pretty performant using those

what specifically are you running into problems with?

Navigator animations dropping frames

hm yea... are you trying to

have the

sliding back with a finger?

like Safari style?

Not even.

just pressing tap?

Yup

Back

hmm

The back is no problem

yea, I know very little about NavXp... tried it literally for a few hours

But I think the fact that a transact is happening plus a large part of the ui is updating is competing with the forward animation

and gave up switching lol (my goal was to try to make the sliding finger as back work with a very native feel)

Ahhh

but it's not critical for our app at all so I gave up

ah yes

so one trick I've done

if your next/coming in screen has a ton of views

Placeholder?

it might lag, yes

so it depends on what your UI looks like

but you can do what I'd call

incremental hacky rendering

lol

Lol

1 sec

No prob

@levitanong have you tried wrapping app-logic parts of callbacks in those?

(def interaction-manager (.-InteractionManager ReactNative))
(defn run-after-interactions [f]
  (.runAfterInteractions interaction-manager f))
;or
(defn later [f]
  (fn []
    (request-animation-frame #(run-after-interactions f))))

@misha yup, I have! Fixes some problems, but not others

also, going forward to a blank page, and later refreshing it with changes (like slack does upon start up) - helps too

@levitanong so you have something like

(om/set-state! this {;local state performance optimizations
                     :perf-load-1                     false})

it is tall js tower on top of huge amount of RN code, after all

Hahaha

(animated-timing-start
        (animated-timing
          bottom-anim
          anim-m)
        (fn [_]
          ;allow loading of cards
          (u/log-transact! this `[(~'cards ~(hash-map :f (fn [_] :loading)))
                                  :cards])
          (om/update-state! this #(assoc % :perf-load-1 true))))

render the thing after the animation is done

similar to what @misha suggested I think

Yeah

but you do it manually for parts of the UI

not pleasant but you gain the most control

It's kind of weird though. The big stuff changing isn't even being animated. It's on a different part of the UI

mine was kinda of a code organization/design problem from the start

I guess I'll have to try with a timeout first haha

Sounds like a design problem on my part too. Haha

so we have a checkout flow and it loads all the views all at once

+ this is the exact reason RN animation is done by mutating ui nodes' attributes directly, bypassing lifecycle methods train

so any time you have a big jump in the number of view on the screen

it might cause frames to drop

Yeah

like with one tap the # of views on the screen jump by like 100!

since it renders a ton of forms and nested views

That's the tricky thing about iPad. :( so much space

ahhh yea

didn't think of that - but good to keep in mind if I ever focus on iPad

use the perf monitor

to see how many views you're adding to the screen at once

it should show view count

if routing animations happen on the main thread - you share those 16ms you have to run your logic with animation logic

@raspasov Ahh, didn't know that's what it was for. Was only using it to look at FPS

and if you can keep it low or split it into chunks of showing up, it should help

there's a thing that counts, the views yes

perf monitor is pretty much useless on simulator

oh yea

and also on dev builds!

lol

@misha: haha I'm using a real device so I expect it to be really useful

btw @levitanong you're testing all of this with a prod build right?

perf on a dev build sucks big time

Dev build

oh!

Ah

try production

you'd be amazed

Hahaha

Ok I'll try

like easily 2-4x difference in perf

Hopeful!

I can bet on that : )

But will perf monitor exist on prod?

will keep you busy fixing "cannot build production because of reasons" errors for a while

nope

Ok thought so haha

Ok this is enough for me to go on.

that's the most annoying part of RN tbh

how long it takes to make a prod build

Thanks @misha and @raspasov!

np ofc, any time

I use RN every day so chat any time!

Awesome :D

we have a prod app with it

live*

Nice

btw final thing: GREAT library

Will try not to abuse your hospitality

that I just found

@levitanong appreciate it, np : )

https://github.com/oblador/react-native-animatable

it can actually be so great to animate parts of the UI with placeholders!

this one might help too: http://browniefed.com/react-native-animation-book/API.html

very nice declarative animations, should have used it sooner

@raspasov: oh hey that's great!

Will play with it. Thanks for he heads up!

@misha I like their Animated API a lot too! it's actually just at the right level imo to make great custom animations

@misha yeah animated is pretty cool for custom animations

but the animatable library def is faster to get started for many cases

Anyway, gotta go guys! See ya! Thanks again!

ttyl!

not linking just API, but an actual book – great read for understanding what's up

has anyone updated to xcode 8.2.1?

also, has anyone gotten om.next to work with boot-react-native?

@levitanong Xcode 8.2 right now, I use re-natal, it has worked well