Seems like the time has come for the synergy of native + JavaScript. React.js are not the only ones working on it... Tabris.js works on a similar principle (combine the best of native and web) and offers features like instant debugging of JavaScript on your device. It's currently invite only.
A Deep Dive on React Native [video]
61–70 of 72 posts
Re: A Deep Dive on React Native [video]
#62https://www.infinum.co/the-capsized-eight/articles/running-j...
This article have lot of details about how JS is getting executed on the Native platform. Lot of components are provided by Apple like JS VM
Re: A Deep Dive on React Native [video]
#63Earlier quoted context omitted.
If you have to watch a video though, try increasing the playback speed (it's in the little settings gear on the YouTube player). I normally listen for a few minutes at double speed, then drop down to 1.5 if necessary.
Did you try that with this video? I had enough trouble with the speaker rushing words in a thick accent at normal speed (not even meant as a criticism...just one of those things you come across at these conferences). Sometimes speeding up just isn't a viable option. I'm glad I had the time to watch the whole video last night, but I too am looking forward to blog posts, documentation, and code releases. Way easier for…
I actually don't find him that difficult to understand at 1.5x. But it's probably a matter of exposure -- as a German living in Europe I'm used to all kinds of European accents in English and common mispronunciations, whereas I'd probably barely be able to keep up if it was an Indian accent, for example.
Re: A Deep Dive on React Native [video]
#64I'm curious about animations. That is one thing React hasn't really figured out on the web. I think the last experiment I saw was to do all the animations manually using component state. I wonder if this is the same on Native? Ideally a cross pollination of ideas about animations would make both ecosystems better.
I've done a bit of work on React Native animations. We are mostly working on two experimental animation APIs.
One is implemented fully in JS and is used when we need to implement gestures and respond to ongoing touch interactions. This is tricky because we need to be very careful to keep our JS frames very short and fast during the gesture, avoiding expensive allocations and making sure we don't try to process too much data in Relay.
The other API is much more magical. You configure the animation for your component immediately before a setState. The new layout is computed normally, but instead of directly updating the native views, we use POP[1] to animate to them on the main thread. This is a really easy-to-use API, but there are a few caveats.
We're still developing, stabilizing, and cleaning up these tools. It's great to hear your interested in this, we'll try to open something up before too long!
Re: A Deep Dive on React Native [video]
#65Earlier quoted context omitted.
Yup, but it's not necessarily UI state that gets updated, just something that maps draggables to where they've been dropped.
yes, like updating the position in a sorted list you mean right. And did you also get it to work with touch events on mobile? I have an open question about that on SO http://stackoverflow.com/questions/27837500/drag-and-drop-wi...
Simply adding jquery-ui.touch-punch[0] monkey patched jquery-ui without us having to do anything else.
Re: A Deep Dive on React Native [video]
#66React Native is a cool project, but the deafening hype is slightly puzzling. Creating and calling native UI components from JavaScript is nothing special in itself. It's obviously possible to do it from JS just as well as from any other language -- you just need to provide the API. There you have two choices: either a bridge that translates the native API directly, or a wrapper class hierarchy. Examples of bridges in…
React Native doesn't presume to know how to build cross-platform apps. But we want to enable people to do that.
That results in two different classes of Native components:
- Cross-platform components that are nearly identical on each platform- Eg. , , , , . There will not be many more of these
- Platform-specific components- When there is not an identical API and feature-set, we provide bridged components which can take full advantage of the platform. There will be a lot of these, but we currently only have a handful.
The real power comes from React's component-driven declarative programming style. The asynchronous batched bridge is well designed, but it's nothing special.
Re: A Deep Dive on React Native [video]
#67Earlier quoted context omitted.
The executable code limitation is likely geared toward security. For all other purposes, it's just data.
Well yeah, both are for security. But if you had a native "app server", that just fed JS to a shell of an app that had ReactNative in it....you could completely change the app, remotely. Not just styling too, but actual functionality. Its the promise of "real" native A/B testing, but clearly violates app store review guidelines.
We submitted an app a while back (mid 2012 I think) that ran a dynamically interpreted language developed in-house. The objective-c codebase was fairly small, nearly the entire app was written in this language stored in external files. Right before submission we decided not to risk being rejected for the reasons cited, and instead baked-in the scripting files, but clearly kept open possibility of remote load for future submissions. We got accepted without issue, but that app ended up being decommissioned and we haven't revisited the approach. Sometimes I wonder if Apple would have let our original submission through if we remote loaded the code instead.
Re: A Deep Dive on React Native [video]
#68React Native is a cool project, but the deafening hype is slightly puzzling. Creating and calling native UI components from JavaScript is nothing special in itself. It's obviously possible to do it from JS just as well as from any other language -- you just need to provide the API. There you have two choices: either a bridge that translates the native API directly, or a wrapper class hierarchy. Examples of bridges in…
I think the hype is partly because many people (myself included) really like, even love React (and Flux). So being able to use it for native apps is great news for us.
My day-to-day is very heavily skewed to app development rather than web development, but in my off-time I've been messing with React/flux. I have no issues with writing the objective-c, but the unidirectional style of React has been a real joy to work with and I've been thinking "How can I best imitate that while working natively?"
This could be the answer to that, and I wouldn't need to hack my own idioms together.
Re: A Deep Dive on React Native [video]
#69The next logical step here is that this gets wrapped by an Om-like and then we are writing native apps in clojure! That is pretty exciting to me.
Re: A Deep Dive on React Native [video]
#70I see that they're using display:flex for layout, for all elements, which makes things like inline styles impossible or extremely inconvenient. http://jsfiddle.net/u8wd8kdL/5/ If I am wrong, please provide me an example of how to layout that text with display:flex.
I think it's worthwhile to note that they aren't using CSS, they're using a CSS-like syntax as a constraint solver. This means they're able to define new properties or reinterpret things to suit the native platforms they're building for.