has anyone run into “uncaught error: assert failed: c” when using the react-native button such as: (def button (r/adapt-react-class (.-Button ReactNative))), i.e. this exception is thrown when button is defined in that manner

@acrognale just played yesterday with button - onPress is required, maybe it was a reason

@acrognale I think that error is reagent complaining about you not having a react component as input to adapt-react-class. Are you sure you are using the latest version of React Native? If I’m not mistaken the button was added in 0.37?

@vikeri that was definitely the issue, thanks!

i am having issues when trying to create a simple controlled input with re-natal and om on Android. The component is wired to the state like most examples do: (rh/text-input {:value (or (:name (om/get-state this)) "") :onChangeText #(om/set-state! this {:name %})})

however when typing in the field, it lags heavily and thereby distorts the user input

it's even more noticeable when I keep pressing backspace

it might be a performance problem, but it happens even with a production build and disabled dev mode in rn. The same pattern in plain JS react-native works fine on the same phone, even when in dev mode

I also keep getting warnings from om about queries taking a long time, but that goes away without dev mode

is there a reason why performance would be worse with re-natal than with plain JS?

so @tobiash you mean om-next + react works fine in browser but same stack on mobile gives lag?

no, i tried it in a "vanilla" react-native project

oh, maybe it’s om-next itself. re-natal makes almost no changes actually under the hood

I'm reading through om/next's code and for some reason (om/set-state) is doing more than calling react's setState

oh yeah, reading om code is interesting exercise 🙂

It could be that om actually doesn’t update state immediately and instead using smth like requestAnimationFrame to batch rendering together

oh, nevermind, i just found the solution, and it was there in the docs all along: get-rendered-state

it's not just set-state thats different in om, get-state actually has completely different semantics from plain react. should have read the documentation more thoroughly... spent hours on this just to find this now 🙂

Thanks @harrybin - that was exactly what I needed.