Hacker News Reader

re: react-navigation, I am one of the two primary maintainers of this project and I started working on it in January of this year because it was in a pretty rough state. I think it has come a long way in that time even though there is still plenty to do. I would love to hear what simple things have taken hours for you when using it, feel free to reach out on Twitter in DM @notbrent or email brent at expo dot io. Also, the roadmap for our next major version is here: https://github.com/react-navigation/react-navigation/issues/....

Just want to thank you for your effort, you rock!

Short summary is, well, the drawer is all sorts of weird. How the drawer interacts with everything else is also kind of weird. How to open a drawer with a NavigatorService is not something I could find documented outside of Github, and the comment there was old and what was suggested didn't work.

I have also seen people post suggestions on how to use the library that are just flat out wrong. Suggesting using props that don't exist (!!!???), and I've seen at least three recommendations of how to do lazy loading. Now that the docs are better these issues are going to go away, but unfortunately old blog posts (and github threads) live on.

Speaking of the documentation, it has gotten 10x better over the last few months. It has a ways to go, and pictures would be super nice. The React Native community likes to post Expo apps to showcase APIs instead of having super robust examples in the docs, I get why (and sample apps can be super useful!), but sometimes a "this option results in this" doc is super useful.

When I was first learning the library, some of the documentations labeled navigationOptions, some of them didn't and just passed it in positionally. It looks like the docs have been cleaned up, hopefully other examples around the web do the same thing. When I was trying to learn the API, this was very confusing, but I think if I had to learn it from scratch today, it would be a lot easier.

(If Steven Girder hasn't updated his examples, ask him to! His RN course is insanely popular and introduces a lot of people to React-Navigation)

So I guess saying it is bad isn't correct, but up until very recently, doing anything with the library was an effort in frustration just because of the documentation.

I'm still going to DM you some questions about the drawer though! :) (Update: answered, I was doing some things wrong, and Drawer is being rewritten to make more sense!)

> That and just how very fragile the entire JS eco-system is. Running NPM Update ranges from doing not much at all, to breaking my entire system making deleting all of node_modules the only realistic fix.

That just sounds like a poor understanding of dependency management.

Blindly running 'npm update' means just 'update all dependencies (respecting semver versions in package.json)'. You're going to have a bad time doing that, if you do it rarely, because a lot of stuff is going to update at once. The same applies in most ecosystems (maybe with exception of Elm that has strict enforcement of semver).

Sensible practice is to do something like 'npm outdated' (ideally in CI) to inform yourself of outdated packages and then manually update specific top-level dependencies judiciously, and re-run your test suite against them.

> That just sounds like a poor understanding of dependency management.

And yet a lot of tools and large packages will spit out an error telling the user to run NPM update. As someone who is new-ish to JS, I generally try and follow the recommendations of those who are supposed to know better.

> The same applies in most ecosystems (maybe with exception of Elm that has strict enforcement of semver).

I previously did C++. Breaking changes were few and far in-between. It helps when the library is only updated once every few years. :-D

Now days? Things that break in my environment:

1. Android Studio, I have never not had 2-3 hours of down time after an upgrade. Mostly involving... The Android Emulator. After updates, it just doesn't start. This leads me to: The images on the Android Emulator. I finally have found one that works reliably, I am sticking with it.

Finally, Expo. It is just odd in places.

That is pretty much my entire development stack, short of my editor. Happily enough, VSCode updates just fine.

I have the RN debugger working more or less. There is a Cross Origin Resource error that occurs everytime RN opens up chrome, it opens chrome up to localhost, and I have to type in my IP address instead, which is a bit odd, but the debugger now attaches reliably, so compared to what it was like before, I'm good.

The Expo client is random. It tries to install Expo on the Android emulator all the bloody time, sometimes it works, sometimes it doesn't. I just want Expo to open. I have to use the client to open the emulator if my IP address changes, and this can take 10-15 minutes to jump back and forth between trying the command line client and the GUI client, eventually one of them opens my app.

And then if I login to my app too many times in the emulator, I max out the # of connections allowed to google's auth service and I have to shut down the emulator to close the connections or else I can't login again. I'm guessing it is a bug with how hot loading code works (not cleaning up open network connections?), but at least I understand the fix for it.

Basically the entire RN development stack seems like jank.

Also JS taking 5 minutes to compile blows my mind. I've compiled entire embedded OSes in less time than that (and they did more!).

> And yet a lot of tools and large packages will spit out an error telling the user to run NPM update.

I've honestly never encountered an error with a message telling me to blindly run npm update. What's a package that does this?

never had problems with expo, the emulators dont hold state if you close them, only time it will reinstall is if you close and open the emu OR expo client has updated but you get a prompt asking to update

FWIW I regularly (every month-ish) update all my dependencies in my native iOS projects (cocoapods) and it’s exceedingly rare that things break and when they do, it’s a matter of tweaking <15 lines of application code to fix. Stuff really only gets ugly if you go upwards of a year without updates, and even then it’s still somewhat manageable.

So maybe some library ecosystems are worse than others.

I've had the same experience with the current enterprise Android project I've developed and maintained by myself (at a company). I have my library versions all in my top level gradle file and every few cycles I'll go through and update everything to latest and just build the app and see what happens. It's rare anything bad happens at all. I encounter far more trouble upgrading gradle and the build plugin itself than my dependencies.

> I encounter far more trouble upgrading gradle and the build plugin itself

Could be time to switch from Gradle to Bazel. It would also be nice to see the last of Apache Groovy, don't you think?

> Running NPM Update ranges from doing not much at all, to breaking my entire system making deleting all of node_modules the only realistic fix.

Why not just pin your dependencies to specific versions, ie - “somepackage”: “4.2.9” ?

I'm borderline infuriated that this isn't the default way that npm works. Maybe if people didn't willnilly break things and followed semver, it'd be okay, but I waste too much time bisecting why some package that used to work is blowing up my build or failing in less obvious ways.

But I'm a crusty almost-30 .Net developer used to Nuget.

npm does maintain a lockfile for you by default since npm 5, if that's what you mean.

There really is no reason to be encountering surprise sub-dependency changes with npm.

Happens all the time when package.json defaults to foo: "^1.2.3", and some bozo does breaking changes in 1.2.5.

If you have a package lock, even caret in package.json won't automatically install it.

> Happens all the time when package.json defaults to foo: "^1.2.3", and some bozo does breaking changes in 1.2.5.

No it doesn't. Since npm 5, npm is lockfile-by-default, you don't get updates unless you ask for them. Whether one particular package correctly respects semver is irrelevant.

Because that's not how it works. Subdependencies are still liable to slight shifting - of course there is the shrink-wrappish package-lock and npm ci, but they do some weird things I don't want to elaborate here.

Npm is more fragile than it should be.

Having to delete node_modules to “fix” it is indicative of a poor package manager. Although not entirely the same, it reminds me of cabal hell, in Haskell many years ago.

I've had to do that with every package manager though.

After working with pip and gradle I have never encountered that issue

It's not related to RN but you touched on something with NPM that made me realise that, for some reason, I never trusted its `update` command. If I wanted to update a specific dependency to a new version I would take the `apt` approach and just install it again, or tweak the version number directly.

Contrast this to how I've approached it in, say, Ruby...I'm very confident in blindly running `bundle update` and checking the diff to see the result.

I've been using react-native-navigation from Wix. The documentation is a little sparse but so far I've gotten it to do everything I need it to do.

Me too, so far it has been the best solution. Some things you have to fiddle with for a long time to get working. But overall very good.

Hi! I've contributed at lot into RNN and love to read comments like yours. I feel the library is very underestimated by the community and IMO should be maintained and shipped with React Native by default.

I've been planning to switch to V2 in our starter kit for the next major release.

https://github.com/ueno-llc/react-native-starter

re: [0] you can probably declare fetch as global variable in your linter config to fix that.

indeed! this plugin does the trick too: https://www.npmjs.com/package/eslint-plugin-react-native-glo...