#Do I really need to add ": JSX.Element" to every function in React page?

26 messages · Page 1 of 1 (latest)

hollow oyster
#

This is my home page:

function Home (): JSX.Element {
  return (
    <div>
      Test
    </div>
  )
}

export default Home

Do I really need to put JSX.Element there on every single page? Seems daunting.

My TS complains about it here: 1:1 error Missing return type on function @hazy maple-eslint/explicit-function-return-type

hot elm
#

You don't have to, you can turn that lint rule off if you don't find it helpful. (Unless you can't)

hollow oyster
#

So I have no choice but to put that to every page function? xd

hot elm
#

Basically, yeah. I guess write a snippet for it.

#

This is what pushes some people to use React.FC, but I still think that's not great.

hollow oyster
hot elm
#

Odds are good you have React imported anyway, but with FC you've got to annotate the entire function which has some downsides

#

!reactfc

hazy mapleBOT
hollow oyster
#

Oh no, I was wrong actually, just checekd the client old commit and that is off

#

not sure why this is on then

#
{
  "env": {
    "browser": true,
    "es2022": true,
    "node": true
  },
  "extends": [
    "love",
    "plugin:react/recommended",
    "plugin:@next/next/core-web-vitals",
    "plugin:@typescript-eslint/recommended"
  ],
  "parserOptions": {
    "ecmaVersion": "latest",
    "sourceType": "module",
    "ecmaFeatures": {
      "jsx": true
    },
    "project": "./tsconfig.json"
  },
  "settings": {
    "react": {
      "version": "detect"
    }
  },
  "overrides": [
    {
      "files": [
        "**/*.ts",
        "**/*.tsx"
      ],
      "parserOptions": {
        "project": "./tsconfig.json"
      },
      "rules": {
        "react/prop-types": "off" // Disable prop-types rule for TypeScript files
      }
    },
    {
      "env": {
        "node": true
      },
      "files": [
        ".eslintrc.{js,cjs}"
      ],
      "parserOptions": {
        "sourceType": "script"
      }
    },
    {
      "files": [
        "**/*.jsx"
      ],
      "rules": {
        "@typescript-eslint/no-unused-vars": "off", // Since it"s a JSX file, TypeScript specific rules should be turned off
        "@typescript-eslint/explicit-module-boundary-types": "off", // Disable TypeScript specific rules for JSX files
        "@typescript-eslint/explicit-function-return-type": "off"
      }
    }
  ],
  "rules": {
    "react/prop-types": "off",
    // "typescript.updateImportsOnFileMove.enabled": "always",
    // "javascript.updateImportsOnFileMove.enabled": "always",
    "react/react-in-jsx-scope": "off",
    "@typescript-eslint/space-before-function-paren": [
      "warn",
      {
        "anonymous": "always",
        "named": "always",
        "asyncArrow": "always"
      }
    ],
    "@typescript-eslint/explicit-module-boundary-types": "off",
    "@typescript-eslint/no-unused-vars": [
      "error",
      {
        "argsIgnorePattern": "^_"
      }
    ] // Ignore unused variables starting with an underscore
  }
}
#

Am I messing things up? xd

#
src\app\_components\Header\MenuMobile.tsx
  8:1  error  Missing return type on function  @typescript-eslint/explicit-function-return-type
#

Why would it throw this error then

#

if its off

#

"@typescript-eslint/explicit-function-return-type": "off"

#

its off, and ye it says its missing 🤔

hot elm
#

It looks like it's only off for .jsx files

hollow oyster
#

Ah indeed.

So does that mean the client wants that rule then? xd

hot elm
#

You'll have to ask them, I guess.

#

FWIW, I'd largely consider explicit-module-boundary-types the better version this rule; same deal but only applies to things that are exported.

hollow oyster
#

I asked them, and they do wnatn that rule off. They forgot to extend the jsx to other stuff.

So that will be off then.

hollow oyster
# hot elm FWIW, I'd largely consider `explicit-module-boundary-types` the better version t...

I wonder, I'm bit ignorant on this as I never properly setup this stuff myself tbh, but because he has a vscode setting with some of these rules, and it will go red if it doesn't match it. Is that the same thing, or equivalant give or take?

I'm trying to bring both of different code editors to work and enforce eslsint with what the client wants, in case you use phpstorm, i vscode, we have the same enforcement

Using huskey for that and lint-staged