elyukai / optolith-client

Optolith Character Manager is a desktop application for The Dark Eye 5th Edition.
https://optolith.app
Other
162 stars 44 forks source link

React devtools and displayName #575

Open flying-sheep opened 4 years ago

flying-sheep commented 4 years ago

Hey, I started looking at the code and realized that it’s not super easy to debug the React component hierarchy. Adding devtools is pretty easy by adding this (or a more cross-platform version of it) to main.ts:

BrowserWindow.addDevToolsExtension (path.join (
  os.homedir (),
  ".config/chromium/Default/Extensions/fmkadmapgofadopljbjfkapdkoienihi/4.0.6_0/",
))

But the resulting devtools view shows all React components as “Anonymous”.

I guess that’s because we use a lot of anonymous functions as components, and neither tsc nor the React devtools infer names for them like the Firefox or Chromium debuggers do.

Does anyone know how to improve this? AFAIK tsc doesn’t have compiler plugins that we could use, and I think it would be overkill to use babel or so just to get this feature.

elyukai commented 4 years ago

Yeah, I realized that, too, but it's way easier to write and type them in arrow syntax (using React.FC<...> is quite helpful for not returning an invalid type.

Well, we could convert them to function syntax but that'd make the types harder to write and I don't consider

const Wrapper: React.FC<Props> = function Wrapper(props) {

a nice style because of the duplicated name. Either

const Wrapper: React.FC<Props> = props => {

or

function Wrapper(props: Props): ReturnType<React.FC<Props>> { // or sth like that

but I prefer the former because it's only one type annotation instead of two for the same thing.

It will eventually be fixed when using ReasonML for them since it emits function-style functions and components but I don't know yet when all of those components will have been converted to ReasonReact.

flying-sheep commented 4 years ago

I prefer arrow syntax for functional code as well. If we want to fix this we could switch from directly using tsc to using babel, but IDK if that has a performance impact, and if we accept the added complexity. Something like:

.babelrc:

{
  "presets": ["@babel/preset-typescript"],
  "plugins": ["@babel/plugin-transform-arrow-functions"]
}

package.json

 {
   "scripts": {
-    "ts:build": "tsc",
-    "ts:watch": "tsc --watch",
+    "ts:build": "babel src -d app --copy-files",
+    "ts:watch": "babel src -d app --copy-files -w",
   }
   "devDependencies": {
+    "@babel/cli": "^7.0.0",
+    "@babel/core": "^7.0.0"
+    "@babel/preset-typescript": "^7.0.0"
+    "@babel/plugin-transform-arrow-functions": "^7.0.0"
   }
 }
elyukai commented 4 years ago

Well tsc is already pretty slow (compared to bsb) so I don't think I'd make things worse as they are already! 😜 I guess, we should try it.