Maison > interface Web > js tutoriel > le corps du texte

Pourquoi je préfère les déclarations « fonction » pour les symboles de niveau supérieur (mais je ne les utiliserai plus)

Patricia Arquette
Libérer: 2024-10-24 06:18:02
original
965 Les gens l'ont consulté

Why I Prefer

Aujourd'hui, nous avons décidé d'utiliser les fonctions fléchées exclusivement au travail.

Nous avons une configuration ESLint commune et l'équipe a voté pour unifier cette règle dans tous les projets.

Et honnêtement, je ne suis pas fan de cette règle particulière

Personnellement... les déclarations de fonctions semblent plus expressives, du moins pour les symboles de niveau supérieur :

quelque-écran-de-mon-app.tsx

import {} ...

export function SomeScreen(props: Props) {
  const { myContext } = useMyContext()
  const [state, setState] = useState()

  const doSomething = () => { ... }
  const handleSomething = () => { ... }

  return <>...</>
 }

function SomeInternalComponent() { ... }
Copier après la connexion

C'est ainsi que j'ai l'habitude d'écrire des composants : déclarer une fonction ressemble à un titre de chapitre dans un roman.

function Chapter3(storySoFar: Props) {
   // where the Hero meets the Villain
}
Copier après la connexion

Mais je comprends le besoin de l'équipe : selon l'auteur original d'un module, nous pourrions trouver au premier niveau const () => {} ou fonction.

L'argument principal est que "les fonctions fléchées sont plus lisibles" (avec lequel je ne suis pas d'accord)

import {} ...

const SomeInternalComponent = () => { ... }

export const SomeScreen = (props: Props) => {
  const { myContext } = useMyContext()
  const [state, setState] = useState()

  const doSomething = () => { ... }
  const handleSomething = () => { ... }

  return <>...</>
 }
Copier après la connexion

J'ai essayé de trouver un avantage technique pour soutenir ma préférence... un nerd *pitimini* [ quelque chose de petit ou d'insignifiant ] qui fait pencher la balance à mon avantage mais comme nous tous sont d'accord sur ce qui suit :

  • Pas de cours (juste des fonctions)
  • Pas de trucs globaux (modules modernes)
  • Non ça

Il n'y a pas de différences significatives entre chacun.

Plonger dans les détails :

const foo = () => { ... }

  • Pas de levage
  • le nom de la fonction est dérivé du nom de la variable ("foo")
  • Ne peut pas être écrasé plus tard comme foo=...
  • Ne crée pas l'objet prototype foo.prototype
  • Ne peut pas être utilisé comme constructeur new foo()
  • N'a pas d'arguments
  • cette valeur est définie par la fonction est déclarée

fonction foo() { ... }

  • Levage
  • le nom de la fonction est évident.
  • Peut être écrasé comme foo = ...
  • Crée le prototype d'objet foo.prototype
  • new est autorisé comme : new foo() (qui relierait le prototype)
  • cette valeur est définie par comment la fonction est appelée

En fin de compte, je préfère la Clarté supérieure de la fonction pour les composants de haut niveau, mais la volonté du plus grand nombre prévaut.
Je plaisante, je vais m'adapter. Avoir un style unifié aidera à maintenir une base de code cohérente.

???.


merci d'avoir lu

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!

source:dev.to
Déclaration de ce site Web
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn
Derniers articles par auteur
Tutoriels populaires
Plus>
Derniers téléchargements
Plus>
effets Web
Code source du site Web
Matériel du site Web
Modèle frontal
À propos de nous Clause de non-responsabilité Sitemap
Site Web PHP chinois:Formation PHP en ligne sur le bien-être public,Aidez les apprenants PHP à grandir rapidement!