One month with React Native | Hacker News Reader

One month with React Native

whitesmith.co

111 pointsruimagalhaes53 comments

Coming from a background of WebViews hybrid development (Cordova/Ionic), React Native simply blew my mind. How I see it is you get the UI advantages of doing native development, with the advantages of using React for the front-end just like I would for the web and going the native way whenever you need to.

I don't think all projects should be done with it as native development still has its place for certain kind of apps, but for a typical thin-client app wrapping a web service, it's really great.

Even for thicker client apps react native is a decent option as you can always drop down to native code if you need to.

I'm going through a similar experience. I have some experience with Objective C and iOS, almost nothing with Android and I have good experience with (non-mobile) Java. Basically I have a week to build Android app which should be quickly ported to iOS. So far my experience is mixed. React Native feels like very powerful tech. But standard library is very minimal, tooling looks very fragile (it works, but I'm very afraid of the moment when those thousand node-gradle scripts will break), things like navigation look very complicated (I investigated react-navigation, had quick glance over other solutions and finally decided to roll my own tiny navigation and animated menu). Modern JavaScript is OK, I guess, though it's so far from proper typed language with proper tooling like Java.

What I wish to exist is something like Kotlin with react-native like library, with single good cross-platform library of components and good solid tooling.

Facebook developers are awesome, but they are paid for Facebook apps, not for making good library, IMO, good library is just a by-product which they kindly shared and it feels everywhere.

Overall I think React Native is the best cross-platform solution out there. It doesn't carry overhead of bundled HTML webview, its view is advanced enough for complex GUI, it provides smooth animations and React is something very interesting actually. Also you can push updates without app-store approvals, if I got that right (I'm not sure about Apple). For apps built in haste with multiple bug-fixes every hours it's important.

Navigation is indeed a hairy beast right now. We're working hard to get React-navigation in shape for 1.0. I think the solutions from Wix and Airbnb are fantastic -- but the community deserves a really polished, JS-only solution that's ready for production. I hope you take another look at React-Nav when we release 1.0!

Disclaimer: I work on React Native, react-navigation, etc @ Expo (expo.io)

> Kotlin

isn't Reason supposed to fill this role?

I recommend https://github.com/wix/react-native-navigation for now, the docs is well done and makes it easier to integrate with. The UI part is implemented natively, but you interact with it on the JavaScript side.

AirBnB just started working on one too that seems promising, but it's not ready for primetime yet.

>But all of this doesn’t come without a price for someone that, like me, is a heavy user of the ctrl+space code completion features of both Xcode and Android Studio.

What about using Visual Studio Code with the compiler set on 'checkJs'? I've just started using TypeScript and I don't think I can ever go back to raw JS.

Same. I evangelize TypeScript whenever I can. I don't think I'll ever be as efficient in JavaScript as I am in TypeScript, now that I've tried it. Granted, it has its quirks, but (especially when writing React) it's invaluable to me.

How does typescript compare to flow? I'd love to see a comparison with pros n cons. I haven't tried either yet and I'm curious if you have any recommendations re resources to read.

Just wait for the next job where they will put you to maintain old angulajs1 app..

> Next, plan your Redux store ahead. I feel like I made the mistake of overusing it. Almost every property of my app is managed by Redux and this results in large reducers and many many actions to control all that. It’s very important to figure if some prop will be needed outside a certain component or not and, if not, keep that inside that component.

How can you possibly know _in advance_ if a prop will be needed outside a certain component (you haven't written yet) or not? This seems to imply a suggestion to completely architect the entire app (what components exist, how they relate) before you write much code. And then somehow being correct, even as you develop the app and add new features etc.

I haven't done anything with React Native, and am only a beginner at web React, but this kind of data management architecture has definitely been one of my biggest challenges. I find it hard to change things once they're there, but hard to know what should be there up front.

>>> How can you possibly know _in advance_ if a prop will be needed outside a certain component (you haven't written yet) or not? This seems to imply a suggestion to completely architect the entire app (what components exist, how they relate) before you write much code. And then somehow being correct, even as you develop the app and add new features etc.

In engineering, that's what we call the design phase.

That's cool, is there a "user story" for that?

Just draw what you're building on a piece of paper. That's going to force you to think through a lot of it. Amazing how few FE engineers will do this.

Tutorial link for executing this type of 'drawing'?

I can't even find the API docs for drawing to "paper." They need to work on the usability and make it a proper open standard, like HTML Canvas!

Redux has a great piece of their tutorial that deals with this problem:

http://redux.js.org/docs/recipes/reducers/BasicReducerStruct....

Here are a few gotchas to avoid:

1. Define your state shape in terms of your domain data and app state, not your UI component tree.

2. Your reducers do not need to have a 1 to 1 mapping to actions. If you need to fire multiple actions to change the data you need then rethink your reducers.

"Define your state shape in terms of your domain data and app state, not your UI component tree."

I'm not sure that's what OP is recommending though? In fact, that redux doc seems to me to making an opposite suggestion to the OP -- it seems to be suggesting you should put domain data, app state, and UI state all in the store, but "define your state shape in terms of your domain data and app state, not your UI component tree." OP seems to recommend trying ot keep app state and UI state _out_ of the store if you can.

I think people in practice have a lot of trouble with this, and making it successful, even after experience.

But apparently a lot don't too?

I would interpret the comment as by default, don't use the redux unless you need it. And when you go to use it, think about it.

You can make that effort of thinking the component architecture ahead and that will definitely help. To be honest I was thinking more about props that you'll know will live inside a component but end up on the redux store anyway. I made this mistake with forms on my first react native app by having any field value on the store. I didn't really need to that and the store got bigger and bigger because of that first choice.

Then we also get the opposite advice, above, _don't_ think about your component architecture when defining state! "Define your state shape in terms of your domain data and app state, not your UI component tree."

Well regarding IDE's i'd say try WebStorm (by JetBrains).

It has the best React support ever since React existed, and every IDE feature imaginable. And also, its basically the same IDE as Android Studio, so a very small step for a App programmer.

Great post. We have been building our native apps on React Native for about half a year now and it has been awesome. Completely agree with this whole article.

Related: I would highly recommend trying out/using Expo.io if you are new to React Native and just want to get something working incredibly fast/easy to "hack" around with. It's a fantastic wrapper around React Native to jumpstart the whole dev experience.

I have been working on a large React Native project for several months now. It's great for quick prototyping but once we started doing heavy database stuff it got really slow, especially on Android. Of course we could have ported that part to native code, but that kind of defeats the purpose, doesn't it?

Assuming you don't do heavy work in the UI-loop: I find react-native's bridge memory-management on Android rather questionable: [0]

They make heavy use of structures in native memory for argument-passing between JavaScript and Java. Once again someone thought they could outperform the JVM with their C-skills. My critique was dismissed :-/

Even though I showed that giving up RN's native memory and just sending serialised Json-Strings on the Heap over the bridge is 50-100% faster (and doesn't interfere with GC, so it should have less lags as well): [1]

The image library they use, Fresco, does the same. There are many year-old bug-reports open regarding OutOfMemory-errors and crashes, and RN apps tend to get unstable with more images. My bug-report [2] was dismissed as well without proper explanation.

But: At least some guy or girl didn't have to give their custom code up for to the better JVM. scnr

I use Strings for arguments in production and it's faster, so maybe try that out. :)

[0] https://github.com/facebook/react-native/issues/8780

[1] https://github.com/facebook/react-native/issues/10504

[2] https://github.com/facebook/fresco/issues/1363

While there is a vm of sorts on Android, there's no jvm. Is your comment about Android or the (traditional) jvm?

I did all the benchmarks on Android ART. It's not the JVM, but blocking GC is an inherent design problem of finalizers that can't be fixed on any VM.

It doesn't defeat the purpose entirely in my opinion. Even if you write that core native code and use RN for the rest of the app, those elements will be potentially easier to ship and maintain.

You're running a local db of some sort? I'd assume you'd always want your app to be a thin client and just fetch data via REST or RPC.

Our app is used by people working in remote areas without mobile/wifi reception. Therefore we maintain a local copy of the user's state.

What database were you using and what bottlenecks did you run into? Curious as I have yet to work with dbs in React Native.

We are using SQLite. The performance bottleneck is not the database itself but conversion between the Java and JavaScript environments.

Obviously almost every react native app out there is accessing a SQL db over the network, and they work fine. Are you seriously saying that it's slower to get data over the react native bridge than over the internet?

No, such a claim would be complete nonsense.

We are using a local database as a mirror for offline use, which is a key requirement. Profiling (a forgotten art nowadays) shows that most time spent during queries is in this bridge and not in the actual queries.

I know realm has a React Native library which I imagine you could use to access the db directly. Can you do something like that with SQLite? I.e access it without going through java/the bridge?

What was the size of the result set?

Have you tried appending '... LIMIT <count> [OFFSET <skip>]' to constrain the per-query result set to a reasonable size?

Has anyone had experience with NativeScript? Currently trying to compare that to React Native for our next project.

I'd like to see the feedback on this as well. It seems very promising but I wonder what the real-world performance and dev/build/release experience is like.

Why trust this framework when it can't even get a simple iOS navigation bar right. At one point you need to at least write a "bridge" in Swift or Java because RN did not cover even over 50% of the SDK.

React Native vs Xamarin?

Very different approaches. Personally, I'm most intrigued by what Google will show of Flutter at I/O this year.

Also very different approach. Flutter renders all graphics much closer to the metal instead of binding to platform's UI APIs so you're effectively shipping the UI toolkit that will be the same on jelly bean and iOS 10 (or different if you want)

So far it looks like the consensus is that React Native is good for quick prototypes or one-offs that aren't expected to have a long lifecycle.

Can someone point me towards some more in-depth explorations or books on this topic?

https://facebook.github.io/react-native/docs/getting-started...

The official documentation is a good place to start.

Swizec Teller is running a free course at https://school.shoutem.com/. Stephen Grider has a few good video courses on Udemy such as https://www.udemy.com/react-native-advanced/.

http://www.reactnativeexpress.com is a great resource.

I just gave a talk on this at uikonf. Is their anything in particular you would like to know?

Not in particular. I appreciate the suggestion of the official documentation. I do need to rtfm, however after that I will be looking for further examples and explanation. Oh, but if there is any useful tooling I should be aware of that would be quite helpful.

Everything by tal kol from wix re performance optimization is a must read. I also recommend checking out infinite reds GitHub.

The Facebook React Native group is also a great resource.

I just started reading the section on animation from the React Native Cookbook and plan to read the rest. So far so good.

Judging from the table of contents, it seems the book gets into more depth than what else is out there.

Still happy with Jquery-mobile , is Easy ,OOP and Better. React.js is a lost of time as many other framework that try to copy the javaBean concept. When browser support completly ES6 all this framework will be forgotten

But by then everyone currently using es6 will be writing es7 which will be compiled to webassembly with an optimising compiler...

Reply on news.ycombinator.com