Warum ich „Funktions'-Deklarationen für Symbole der obersten Ebene bevorzuge (sie aber nicht mehr verwenden werde)

Heute haben wir uns entschieden, Pfeilfunktionen ausschließlich bei der Arbeit zu verwenden.

Wir haben eine gemeinsame ESLint-Konfiguration und das Team hat dafür gestimmt, diese Regel in allen Projekten zu vereinheitlichen.

Und ehrlich gesagt bin ich kein Fan dieser besonderen Regel

Ich persönlich... finde Funktionsdeklarationen aussagekräftiger, zumindest für Symbole der obersten Ebene:

some-screen-of-my-app.tsx

import {} ...

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

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

  return <>...</>
 }

function SomeInternalComponent() { ... }

So bin ich es gewohnt, Komponenten zu schreiben: Die Deklaration einer Funktion fühlt sich wie ein Kapiteltitel in einem Roman an.

function Chapter3(storySoFar: Props) {
   // where the Hero meets the Villain
}

---

Aber ich verstehe die Bedürfnisse des Teams: Abhängig vom ursprünglichen Autor eines Moduls finden wir auf der ersten Ebene möglicherweise const () => {} oder Funktion.

Das Hauptargument ist, dass „Pfeilfunktionen besser lesbar sind“ (womit ich nicht einverstanden bin)

import {} ...

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

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

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

  return <>...</>
 }

Ich habe versucht, einen technischen Vorteil zu finden, um meine Präferenz zu unterstützen ... irgendein Nerd *Pitimini* [ etwas Kleines oder Unbedeutendes ], das das Gleichgewicht zu meinem Vorteil verschiebt, aber da wir Alle sind sich über Folgendes einig:

• Keine Klassen (nur Funktionen)
• Kein globales Zeug (moderne Module)
• Nein, das

Es gibt keine signifikanten Unterschiede zwischen den einzelnen.

Eintauchen in die Details:

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

• Kein Heben
• Der Name der Funktion wird vom Namen der Variablen („foo“) abgeleitet
• Kann später nicht überschrieben werden wie foo=...
• Erstellt nicht das Prototypobjekt foo.prototype
• Kann nicht als Konstruktor verwendet werden new foo()
• Hat keine Argumente
• Dieser Wert wird definiert durch wodie Funktion deklariert wird

Funktion foo() { ... }

• Heben
• Funktionsname ist obv.
• Kann überschrieben werden wie foo = ...
• Erstellt den Objektprototyp foo.prototype
• new ist erlaubt wie: new foo() (was den Prototyp verlinken würde)
• Dieser Wert wird dadurch definiert, wie die Funktion aufgerufen wird

---

Letztendlich bevorzuge ich die Überragende Klarheit der Funktion für erstklassige Komponenten, aber der Wille der Vielen setzt sich durch.
Scherz, ich werde mich anpassen. Ein einheitlicher Stil trägt dazu bei, eine zusammenhängende Codebasis aufrechtzuerhalten.

???.

---

Danke fürs Lesen

Das obige ist der detaillierte Inhalt vonWarum ich „Funktions'-Deklarationen für Symbole der obersten Ebene bevorzuge (sie aber nicht mehr verwenden werde). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!