@mangofarmer: Do you need the entire framework to validate each keystroke? If so, maybe try using dispatch-sync to avoid waiting until the next render cycle? If not, validate and do anything else you need locally in the component and only dispatch on the final value.

@drapanjanas: I think compilation problem logging to console still works with :heads-up-display false. Or at least I’m still seeing it. Anyway, after my brief dive into the figwheel-bridge internals I think @artemyarulin has the right idea. Do whatever it takes (which apparently is just loading a websockets library?) to have figwheel think it’s in node.js mode. The document and localstorage hacks will probably cause other problems than just my Firebase issue.

Not that this matters (if you do decide to go the node.js route), but my pull request to fix the document and localstorage issues in lein-figwheel was accepted: https://github.com/bhauman/lein-figwheel/commit/fd48fb47328a5318d1bdfeefa7d547f8a026a02a

Thanks @seantempesta I'll try a few options. My current app has a subscription to say which page is being displayed, then the detail page has a subscription to get the list of fields on the form (I need it to be configurable) and then for each form field, generate the appropriate component (mainly a few TextInputs with a text label, but there will be on/off switches etc), and on each keystroke it dispatches to update the field's value back in the appdb. But I don't necessarily need immediate validation, I'll try making the form field components self contained and only fire updates to dispatch when on-blur occurs or something. My issue with this though is that it seems a bit against the way re-frame works. In react native is it necessary to set a unique key property / metadata on components in a list like this? Perhaps too much is getting recreated each time.

@mangofarmer: Did you try using dispatch-sync? I’d say if that’s still slow then you are indeed just running into performance problems. I haven’t looked into profiling react native applications yet, but maybe Chrome tools would work? If it shows that most of the time is react rendering then you’ve got your answer.

Regarding the keys, I think they are automatically set with reagent (om.next certainly doesn’t), but I believe you can override them with a key of your own choosing.

@seantempesta: I had some luck with setting the value into :initial-text and then dispatching the updated text on the on-blur event, which I think will be ok since the data in this case won't get changed anywhere else whilst the view is on screen, nor is it validated at all to limit length or valid characters etc. But I haven't been able to spend much more time on that today unfortunately. I need to get my head around exactly what goes on under the covers though, I think some of the React Native TextInput's optimizations are not quite kicking in when reagent is also in use.