Reactotron: [Docs] Production vs. dev environment

[Ashoat]

Hey folks! First of all, thanks so much for maintaining this package. It's really quite amazing how much Reactotron can do!

I have some feedback/questions regarding the docs.

1. In the installation docs, the code is written using import statements. However, the tips say you shouldn't run Reactotron in production, and suggest that you must use require statements instead of import. Why not update the installation docs to reflect this?
2. The docs seem to be written on the assumption that devDependencies won't be included in a React Native production bundle, but I'm not sure that this is correct. I tested this by compiling a Release variant of my iOS app (using Xcode). Reactotron still initialized correctly, despite being listed in devDependencies. (I think the point of devDependencies is for npm-published packages, so that the published version of a package won't install dependencies only necessary for development.)

(Unrelated to the production/dev question, it would be nice to list explicitly which plugins are "default" and don't need to be .use()'d explicitly. Docs for plugins seem to indicate you have to explicitly .use() them, but it seems a lot of them work without being .use()'d.)

[skellock]

Heyo! Thanks for taking the time to write up some feedback.

Dev vs prod

This is tough. I've flip-flopped several times and I've come up with several goofy solutions, each more cringeworthy than the last.

Peak cringe for me was a babel plugin. Although it works, and people are using it in production, it scares me that it could transform your code into something that just doesn't work at all.

I'll spare you the historical reasons, and fast forward to where I am right now.

These days, I want to install this as a dependency and not a devDependency. In 1.x, we used socket.io which added way too much overhead for me to be comfortable with. In 2.x, that's gone... and the only thing holding me back from recommending a dependency is our use of ramda. It's a bigger dependency that I'd like to eject.

metro governs what goes into a react-native bundle, and it will pick up only modules in use. AFAIK, it's possible to dodge dependency modules with use of if (__DEV__). Where this gets awkward is with import being hoisted by babel... so, that's why its not safe to use that vs require.

Having said all that...

TL;DR:

Use dependencies if you don't care about an extra 75-100kb (I don't anymore). In react-native apps, this is not a big deal at all (yes, I'm going to hell... i'm now ok with this fate). The big upside is that its possible to debug in production builds (no, don't ship it to the store enabled, lulz)!

If size matters (again, lulz), then you have to do the if __DEV__ dance which amounts to more code to dodge the reactotron-react-native lib coming in.

Default plugins

For react-native, I highly recommend using .useReactNative() vs .use() + the individual plugins.

The real reason why is you can still turn them off by passing false in the config object of the 1st param. For example, here's how you'd enable all react native plugins except for async storage:

.useReactNative({
  asyncStorage: false
})

Sad Docs

Yes, and that's my fault. It's on the top of my list & mind once I get time away from client work.

Thanks again.

And thanks for everything you do for the react-native community!

[Ashoat]

Thanks for the quick response! I didn’t realize Metro was smart enough to strip requires gated behind __DEV__ checks, that’s good to know.

Similar to you, I’m not too worried about RN bundle size given it’s not downloaded again every time the app is loaded.

Feel free to close or repurpose this issue as you see fit!

[chuntley]

Ejecting the ramda dependency would be a significant improvement in regards to this issue, especially for react web.

[skellock]

thx all!