search

infinitered / reactotron

A desktop app for inspecting your React JS and React Native projects. macOS, Linux, and Windows.
https://docs.infinite.red/reactotron/
MIT License
14.92k stars 944 forks source link

RFC: Drop Electron #782

Closed skellock closed 6 years ago

skellock commented 6 years ago

Overview

I'd like to drop Electron and replace it with a local Node.js server.

hold for applause

Why?

What do we lose?

Feature-wise? Nothing.

A node-js server (like express, koa, etc) can still read/write files and clipboard. Browsers can drag & drop file uploads for image overlays.

For people who like to run an app instead of a local webpage, they can still use https://github.com/jiahaog/nativefier to wrap it.

How much work is this?

A new reactotron-server package would have to be created and configured to dish up a SPA.

We'd also have to add endpoints for each write operation (sending state, commands, etc). These would be merely pass thru to existing code.

The image overlay would be the only one I don't know how that works. I've never done that before. I suspect there's great React components that will do this just fine.

Keyboard shortcuts would have to be changed from using the command/win key.

Current State of Electron App

The current Reactotron works great, but inside it's ugly. It's about 2 years old and i literally learned react-js. I'd love to modernize this.

We don't have to do this step now, but it might be worth considering since we're in the area anyway.

Summary

This feels like the right step for Reactotron 3.

What do y'all think? Please talk me out of this 🙏 . Or push me 😈 .

ianoshorty commented 6 years ago

Context

I'm a multi-platform developer, full stack, working on everything from backend to frontend, desktop to mobile. I'm an active React Native dev, and use Reactotron most days. I'm not a contributor on the project.

Opinion

I believe integrating reactotron into the RN development lifecycle, in a fashion similar to Storybook would be incredibly useful.

I would be a big fan of this change. I'm also assuming this would reduce memory usage dramatically?

GantMan commented 6 years ago

Context

I'm an IR employee and I've seen Reactotron since the beginning. My gut reaction was "OH NO!" instead of applause at the top of the suggestion. But by the bottom of it, I was convinced!

Opinion

It doesn't weaken the brand, it unleashes it. ALSO, if later you find you need some native code, that can be a plugin! The plugin system gives you the ability to adapt, so make the core simple.

During that rewrite, I'd love to include engineers who can (and are expected) to help contribute regularly. This project + more people will be a wildfire, and hopefully ensure that the project visionaries (Steve and Rich) can put energy towards their awesome creativity, rather than rote maintnence. So I'd love to see a support increase during this changeover!

akaralar commented 6 years ago

Context

I'm a long time mobile developer but a react-native newbie, working on the frontend. I usually have Reactotron open at all times when I'm developing. I'm not a contributor on the project.

Opinion

I have a lot of tabs open in my browser when I'm working and navigating between them is not easy. I might be trying to solve a problem and opening one stackoverflow tab after another, which means the Reactotron tab would slowly get pushed away from a state where you can navigate to the tab easily. If Electron is removed, I would try to wrap Reactotron into an app so that I can cmd+tab to it, without getting lost in browser tabs. One other issue I can think of is that I would probably prefer to modify shortcuts to involve modifier keys again (since I'll be using it as an app), so being able to do that would be double awesome. I think I secretly enjoy removing Electron apps from my mac, so I would be a fan of this change as well.

rmevans9 commented 6 years ago

I think this will bring a lot of freedom to reactotron. In addition to the problems it solves outlined by everyone else here it brings a new possibility to the table. If we are kicking off a node server in the working directory of a project it wouldn't be a stretch to be able to reach into node_modules and find reactotron plugins and dynamically load them into the UI. This has been something that @skellock and I have talked about allll the way back to the first Chain React (over a year now) and just couldn't find a elegant solution to. This provides that. What that means is if we bake in a good plugin setup that finally allows plugins to provide UI we could handle all that 100% dynamically. This opens many possibilities.

rmevans9 commented 6 years ago

PR added to start the process of implementing this RFC. There is still a lot to do but this is trying out a way we could go about this.

rmevans9 commented 6 years ago

@ianoshorty @akaralar

As both of you called out that you are not a contributor of reactotron I have a question somewhat related to this RFC. Is there anything that we (@skellock and I) can do better/change/anything to make contributing to reactotron more approachable? Would implementing this RFC lower the barrier to entry in your guys' opinions?

I am deeply interested in knowing so we can work to break down any barriers to open the door to more contributors hopping on the reactotron train.

ianoshorty commented 6 years ago

I'm going to break up my reply into three here.

Is there anything that we (@skellock and I) can do better/change/anything to make contributing to reactotron more approachable?

This one is a hard one for me to comment on, because whilst I've used Reactotron since the start of the year, I've only really paid attention to it from a OS perspective since our conversations at Chain React @rmevans9. I haven't explored its internals either, so I can't really offer a fair technical comment here. In addition, I am not a pro-active contributor to OS as a whole - though I'm trying to motivate a change here in both myself and the company I work for at present.

Would implementing this RFC lower the barrier to entry in your guys' opinions?

For me personally, yes, purely because I've never touched electron. I have used node (and in particular express + restify + socket.io) extensively for years. Removing Electron is one less black box for me to worry about, and learn how to debug. All that said, this is a very personal comment based on my own skill set.

I am deeply interested in knowing so we can work to break down any barriers to open the door to more contributors hopping on the reactotron train.

IMO, publicity would help you a great deal. I think Reactotron's value comes from dealing with 2 unique problems in React Native development:

  1. The complexity of data introspection as part of state within a React Native app. Once I discovered its power to understand what was happening in my Redux state and watch for change that I was interested in (whilst filtering out the other noise), I was instantly sold.

  2. The ability to debug the application as a whole, without forcing "over-the-bridge" JS debugging in chrome. This one I only learned about at Chain React, but ironically, since that event I have actually run into a circumstance where the Chrome JS debugger behaving differently to the on-device JS engine.

I think if you could find a way to more publically make the community aware of Reactotron (like the talk you did at Chain React), that would lead to more contributors.

I hope any of this ramble actually helps!

ianoshorty commented 6 years ago

Just taking this a step further, I'd like to register my interest in helping with this change, should you decide to proceed with it.

skellock commented 6 years ago

Alrighty... this is a go. We're on the v3 branch and we'll be setting up a project shortly. On our slack workspace we're chit chatting in the #reactotron-dev channel.

Godspeed!

akaralar commented 6 years ago

@rmevans9 I can't say I'm an avid oss contributor, so me not contributing is somewhat related to me instead of reactotron. But in some repos some easy issues are marked as "starter task" or something like that to be less intimidating to newcomers, and there usually is a contribution guide in the repo so that people can read it and start contributing right away. It might explain general architecture or different modules or new ideas for contribution. You've probably seen it in other repos on github.

My other point would be reiterating that publicity will help a lot. I just started with js and react native around a month ago, and since I was a newcomer I had a lot to learn about, so I thought "I better watch these conf videos" and that's why I watched all the conference videos of this year. Then I learned about reactotron in one of the videos, but the other 2 js devs didn't know about it. They were mainly react developers and not react native, so they already had their toolset to debug a react app. When I sent them the video they said "well this is react native though..." and didn't even care to watch. I was an iOS Dev before starting with react-native and they are frontend developers, and I don't know if the case with the other 2 devs in my team is an isolated one or a representative one, but they feel react-native is very mobile-like and different than web, whereas I feel it's very different than mobile and very web-like. That might be creating a disconnect, or that might be just my team. :)

One thing that would help would be more content, not necessarily created by you, about using reactotron. I followed quite a few tutorials and none of them mentioned reactotron while most mentioned redux-devtools. How could that level of popularity be achieved? I don't have a recipe. Maybe going around to more conferences to talk about Reactotron. Maybe adding a few more dev-friendly features (A canny.io page might prove useful in that regard. update: At the time of writing, I wasn't aware canny.io didn't have a free plan). Maybe creating the definitive guide to react native and talking about reactotron in the debugging section. This last one comes from the fact that one of the first tutorials I did was http://www.reactnativeexpress.com mainly because it seemed both comprehensive and up-to-date. It was ok, but now it's been more than a month since I did that, I learned a bit more about the ecosystem and conventions and feel that could have been more comprehensive. At the time I appreciated someone took the time to do that since I'm used to having comprehensive guides by Apple about most of the frameworks on iOS. I'm aware that I'm basically advising you to write a book for free to popularise reactotron :D but I came to see that there aren't many learning materials both comprehensive and up-to-date, and you might use that as a trojan horse to make reactotron more popular. My 2 cents. :)

rmevans9 commented 6 years ago

Thanks for the thoughts @akaralar. All are very valid points and I will give writing that book some thought! (I am being serious here, no sarcasm)

akaralar commented 6 years ago

@rmevans9 I can hear myself talking to newbies saying 'Well we didn't have that book when we were learning... you are a lucky bunch.`

One other thing I thought of would be to somehow reach popular twitch/youtube broadcasters who do live coding and get them to use it or talk about it. You might ask them what it would take them to use Reactotron and implement those in exchange for airtime. Again popular podcasts might get the word out to people that this thing exists. Also with time, I believe the project will mature more and maybe gain new features to be the one stop shop for debugging react/react-native apps.

Raathigesh commented 6 years ago

Interesting discussion here. We recently did the same with majestic. Also we are experimenting with using chrome launcher to launch majestic as an app by providing --app args to chrome. It could be an OK alternative to people who prefer a standalone window for reactotron as well. I'm just excited about the change 💯

imkarthikk commented 6 years ago

You might want to try hellonext (https://hellonext.co) instead of Canny.io for feedback. Free for open source projects. No limits.