Tach!
Diese Struktur ist auch nicht viel besser. Ob man nun statt numerischen Schlüsseln benannte hat, macht das Kraut am Ende nicht fett.
Doch. Das Entscheidende bezüglich abstrakter Datentype nämlich ist der wahlfreie Zugriff! Während ein Array stets komplett durchlaufen werden muss, hat man mit
{key:value}
den value sofort im Griff!
Das sehe ich in dem Fall nicht als das entscheidende Kriterium an. Der Kontext ist immer noch FormData und URLSearchParams. Beide haben entsprechende Methoden, um über den Namen auf die Werte zugreifen zu können. Man muss sich also nicht die anderen Nachteile einhandeln, nur um die angebliche einfache Zugreifbarkeit zu gewährleisten, wenn diese auf anderem Wege mit vergleichbarem Komfort verfügbar ist.
Das Problem in diesem Fall ist aber Möglichkeit, dass Schlüsselwerte mehrfach auftreten können und sich damit überschreiben.
Mit einer dem entsprechenden Datenstruktur ist das überhaupt kein Problem.
Natürlich ist das kein generelles Problem. Es geht hier aber nicht darum eine angeblich universelle Datenstruktur zu erstellen, sondern eine für einen bestimmten Einsatzzweck. Und da sollte man die Eigenschaften diesbezüglich betrachten, anstatt eine universelle Struktur schaffen zu wollen, die sich anderweitig als nachteilig erweisen kann.
Deine Vorschläge lösen alle nicht die Vorgabe, die ursprüngliche Reihenfolge beizubehalten. Wenn du die in deinem Fall nicht brauchst, gibt es immer noch die Methoden get und getAll, um über den Key zuzugreifen.
Der Enctype hat an dieser Stelle nichts in der Diskussion verloren, es geht erstmal nur um eine sinnvolle Datenstruktur.
Nun, multipart/form-data könnte so aussehen;
Ach, ich dachte, du wolltest eine universelle und keine für einen konkreten Einsatzzweck? Jetzt kommst du mit einer noch spezifischeren Struktur um die Ecke.
dedlfix.