Which is severe but has been open for so long just hasn't had any attention from the core team. It's clearly a massive problem and the packager code is... less than friendly.
Its something which has a simple workaround, has no runtime impact and affects a minority(?) of developers using RN.
While it may be frustrating if this is affecting you, its certainly not a severe issue.
I have been part of development teams for two react-native apps, and nobody on either team has encountered this issue yet (with developers working on a a combination of OSX & Windows 10)
I came across this issue last week and alerted the internal packager team about it. We'll get it resolved- even if the issue is avoidable, we can help people avoid it with better tooling, errors, and documentation.
React Native is great. Hands down, so cool to be able to go from developing websites to native apps. I also appreciate reading the release notes and seeing new features and fixes being released so frequently.
I do however experience real issues when upgrading. We tried going from 0.38 to 0.39, but getting the xcode project files to merge correctly has proved difficult for us, a couple of newbies. The new react-native-git-upgrade makes it easier to see the conflicts, but it is still hard for us to make it work. Does HN have any wisdom to share?
Absolutely, if you already know react and are targeting Android only, picking up react-native will require minimal android knowledge, and the docs are great are walking you through the setup bits you need to get developing on-device.
That's partly true, however as someone who uses React Native with multiple production apps, having "real" native experience is invaluable when using React Native. To create a good RN app you need to know how the system works and be comfortable jumping to the native side when needed. If you don't you're bound to create a sub-par app by trying to make everything fit into the web side which is all you know.
It is possible to create an app without native experience, but it is still needed to create a very good app.
In terms of how much React/JavaScript code you should expect to write vs. how much Native code for a production app, it obviously depends a lot on the app but maybe 80/20 might be a reasonable (if totally arbitrary) expectation.
You should only expect to write pure native code when you hit a performance barrier with some particular custom component you're creating and there isn't an existing JS api or a standard/3rd party component which does everything you need already. But when you do hit this barrier, wiring up your own natively implemented module is pretty straightforward.
React Native doesn't abstract mobile frameworks, so you still need to learn it all as far as iOS UIKit and Android SDK (and also learn React Native stuff on top of it).
That said, there is something about coding in mostly one language (javascript) vs 2 or 3 (Objc/Swift/Android) and also have that live app reloading.
In any case, this react stuff is not for beginners and won't make learning mobile platforms easier - you will still need to put in obligatory 10k hours to get good at mobile dev...
Aside from the live reloading and being able to write in javascript as opposed to Swift/Java, the development paradigms of React is just better, IMO. The component-based design patterns and event-dispatching-based control flow just make so much more sense to me than the traditional Android/iOS way of doing things (I have experience in both the web and mobile). It's easier to test, easier to read/write, and easier to reason about. This is just opinion of course, others may not feel the same.
My workflow so far (pre react-native-git-upgrade) has been to `git commit`, then run `react-native upgrade` and say yes to all the prompts, and then afterwards manually `git add -p` the changes that react native wanted to make to my files (the proposed changes made them "standard" and got rid of customizations, but also upgraded legacy parts from the original templates).
For each change, then, I try to upgrade any react-specific code while preserving my own changes to that file.
It's certainly cumbersome and I avoid doing it too often, but I've found this manageable.
Hi guys, do you know if it is possible to create home screen widgets with React Native? I don't see any info about it in docs.
I'm thinking about something complex, like calendar or HabitHub widgets https://play.google.com/store/apps/details?id=com.rstudioz.h...
I'm trying RN now and I must say that for an outsider its very underwhelming, because one might expect more stuff to just work out of the box (surprises the last few minutes: back button not always handled, material design is a plugin, authentication doesn't have an example, etc).
I disagree. From 0 to production, it took me 1 month. I had never done a mobile app before. Granted, I did have React experience on the web - that certainly helps.
I agree that the documentation can be better. My advice is - either contribute, or read the code. You'd be surprised how well commented and documented the code itself is.
Handling things like authentication would be falling into the trap of doing too much. A UI library/framework is an orthogonal concept to handling user registration or authentication. Material design? Let's say I don't like material design - then it'll be just extra baggage.
Thanks for the heads up - I'll continue investigating. I'm thinking about my fav. Android apps (No iPhone since 3gs here) and really, some are material (say Recurrence, Gmail) and most are not (Waze, Pocketcasts..).
This is great, I work on a pretty big React Native app ( http://artsy.github.io/series/react-native-at-artsy/ ) and keeping up to date with the latest version of React Native has been pretty tough when competing with product-based work items.
Facebook is primarily focused on making React Native work great on iOS and Android. But the community is absolutely moving towards full cross-platform support. Windows is already supported, and there are promising experiments to run RN on Ubuntu, macOS, and web.
21 comments
[ 3.6 ms ] story [ 66.0 ms ] threadhttps://github.com/facebook/react-native/issues/4968
Which is severe but has been open for so long just hasn't had any attention from the core team. It's clearly a massive problem and the packager code is... less than friendly.
While it may be frustrating if this is affecting you, its certainly not a severe issue.
I have been part of development teams for two react-native apps, and nobody on either team has encountered this issue yet (with developers working on a a combination of OSX & Windows 10)
I do however experience real issues when upgrading. We tried going from 0.38 to 0.39, but getting the xcode project files to merge correctly has proved difficult for us, a couple of newbies. The new react-native-git-upgrade makes it easier to see the conflicts, but it is still hard for us to make it work. Does HN have any wisdom to share?
Last time I checkes, there was still rather much mobile know-how needed :/
It is possible to create an app without native experience, but it is still needed to create a very good app.
what is a good balance between RN vs pure native? what works and what doesn't?
what about other considerations like power consumption..file size, etc?
Here's a good high-level talk which touches on the balance somewhat: https://www.youtube.com/watch?v=abSNo2P9mMM.
You should only expect to write pure native code when you hit a performance barrier with some particular custom component you're creating and there isn't an existing JS api or a standard/3rd party component which does everything you need already. But when you do hit this barrier, wiring up your own natively implemented module is pretty straightforward.
That said, there is something about coding in mostly one language (javascript) vs 2 or 3 (Objc/Swift/Android) and also have that live app reloading.
In any case, this react stuff is not for beginners and won't make learning mobile platforms easier - you will still need to put in obligatory 10k hours to get good at mobile dev...
For each change, then, I try to upgrade any react-specific code while preserving my own changes to that file.
It's certainly cumbersome and I avoid doing it too often, but I've found this manageable.
https://productpains.com/post/react-native/android-home-scre...
This will help the core team know what should be prioritized!
I agree that the documentation can be better. My advice is - either contribute, or read the code. You'd be surprised how well commented and documented the code itself is.
Handling things like authentication would be falling into the trap of doing too much. A UI library/framework is an orthogonal concept to handling user registration or authentication. Material design? Let's say I don't like material design - then it'll be just extra baggage.
We're still on 0.34 ( https://github.com/artsy/emission/blob/master/yarn.lock#L484... ) now I feel guilty.
Glad to see the project start to stabilize.