Zwei Navis (desktop-first), die mobile per Toggle-Klickbutton aus-/einklappen sollen [4]

Nachdem ich alle const-Namen an meine Namen angepasst habe, funktionieren jetzt alle close-Gründe:
- links wird menueLinks (close-Grund Klick auf Link),
- hamburgerBtn wird headnavButton, navMenu wird headnavmenue (close-Grund body-Klick)
- hamburgerBtn wird headnavButton, navMenu wird headnavmenue und show wird menue-zeigen in der neuen Funktion, wobei letzteres keine const, sondern eine Klasse ist.

Aufgefallen ist mir, dass der close-Grund "Klick auf Link" als Einziger kein "e" in der runden Klammer hat, also kein (e), sondern nur (). Ist das egal, oder so beabsichtigt? Ich würde am liebsten "sprechend" bei allen dreien event reinschreiben.

Ich fasse mal das Wichtigste für mich zusammen, wenn etwas falsch ist, bitte kurz Bescheid geben:

1. Ich habe jetzt fünf Konstanten, insges. vier Funktionen und drei Mal die "Methode" event listener für die drei Close-Gründe. Die drei Close-Gründe rufen dann wiederum die Funktionen auf.

2. Die erste und wichtigste Funktion "toggleButton" toggled das aria-expanded true/false sowie das Ein/Ausblenden des Menüs.

3. Die beiden Funktionen closeDropdownMenu und setAriaExpandedFalse sowie die beiden leeren array-Konstanten dienen nur den bei mir noch nicht vorhandenen Untermenüs.
Sie sind faktisch noch gar nicht aktiv, ein Fehler wird aber trotzdem von der FF-Konsole registriert.

4. Die vierte, zuletzt ergänzte Funktion "closeMenuIfMobile" schließt das Menü mobile. Alle drei closing-Gründe greifen auf diese Funktion zu.

5. Alle drei closing-Gründe rufen "closeMenuIfMobile" auf, aber auch die beiden Untermenü-Funktionen closeDropdownMenu und setAriaExpandedFalse. Die beiden letzteren werden aber faktisch erst aktiv, wenn es Untermenüs gibt und die beiden leeren array-Konstanten mit realen Untermenü-Selektoren versehen werden.

6. Der HTML-Code aus dem Eröffnungspost kann trotz allem JS so bleiben.
Gleiches gilt für das CSS dort, also
- Button ausgeblendet desktop-first
- Button eingeblendet und ul default ausgeblendet im MQ mobile

Geändert hat sich im CSS seit unserem JS nur das Ergänzen der show bzw. "menue-zeigen"-Klasse:

ul.headnav-haupt-ul.menue-zeigen {
  display: block;
}

Stimmt das soweit alles?

Danke für deine Geduld mit mir.

3. Die beiden Funktionen closeDropdownMenu und setAriaExpandedFalse sowie die beiden leeren array-Konstanten dienen nur den bei mir noch nicht vorhandenen Untermenüs.
Sie sind faktisch noch gar nicht aktiv, ein Fehler wird aber trotzdem von der FF-Konsole registriert.


Und wie lautet die Fehlermeldung?

Jetzt kommt keine mehr, aber es gab ja vorher welche, obwohl die Untermenü-Codes noch gar nicht aktiv waren/sind.

Punkt 3 ist nur eine Information für mich, dass auch Codes, die noch gar nicht gebraucht werden, trotzdem Fehler erzeugen. Für mich ist das nicht selbstverständlich und deswegen war ich auch überrascht, dass die 2 Funktionen bislang noch gar nicht wirken, auch nicht irgendwie indirekt.

Stimmt das soweit alles?


Das wird letzten Endes ein gründlicher Test der Webseite zeigen.

Ich meinte nur die 6 Aussagen als solche, also ob ich die dort beschriebenen Dinge soweit richtig verstanden habe, weil ich das in den Kommentaren festhalten will.

Da du auf den praktischen Test der fertigen Site verweist, gehe ich mal davon aus, dass die 6 Punkte inhaltlich stimmen.

Was die zweite, im Grunde "gleiche" (seitliche) Nav angeht... Käme dein Schleifen-Code in post vier zusätzlich zum jetzt erstellten der 1. Nav dazu, sozusagen als bessere Alternative zu einem "unprofessionellen, duplizierten Nav2-Code", der mir urspr. vorschwebte?
Oder wäre dieser Schleifen-Code dann alles, was es insgesamt an JS gibt? Falls ja, dann wäre der jetzt erstellte Code für mich im Grunde irgendwie "umsonst" gewesen.

Post 4 war als Beispiel gedacht, wie man die Konstanten als Arrays definieren kann, um zwei Menüs damit zu erfassen. Auf die einzelnen Elemente kann dann innerhalb von Schleifen zugegriffen werden. Diese Schleifen-Konstruktionen müssen dazu in den Code eingearbeitet werden. Bei dem umfangreicheren Freecodecamp-Code ist dies entsprechend ein etwas aufwendigeres Unterfangen.

In Kombination mit dem komplexen Code der Schleifenkonstruktion in post 4 wirkt es auf mich so, als ob ich da "komplett draußen" wäre. Ich würde mich vermutlich bei jeder Änderung in Zukunft an einer Nav immer fragen, ob das auch die andere betrifft oder ob ein Fehler damit zu tun hat, dass ein JS gleichzeitig beide Navs betrifft.

Mit dem jetzigen Code fühle ich mich hingegen recht wohl.

Für die zweite Nav (sidenav) den Code zu duplizieren und die fünf Konstanten sowie die selbst erzeugten vier Hauptfunktionen umzubenennen, ist sicher "unprofessionelle Holz-Klasse" und manches wird überflüssig wiederholt, weil es ja zwei im Grunde fast gleiche Navs sind (außer dem "inline-block" für die "li" der headnav, zwecks "Nebeneinander").

Aber würde ich den - aus meiner Sicht - Vorteil von zwei einfachen, sauber getrennten JS-Nav-Codes mit einem echten Nachteil oder Schwierigkeit bezahlen?

Ich glaube, ich würde es zumindest mal probieren wollen.
Ich habe stundenlang im Web/YT alle Tutorials und Beispiele zu meinem Anliegen durchgesucht, aber das sicher nicht seltene Szenario von zwei Navs (mit DD-Toggle-Button ect.) hat nie jemand auch nur erwähnt...