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.
Ist es aber. Weil: Übertragen wird ja nicht der Index eines Array sonder übertragen wird der Schlüssel und zwar namentlich! Selbst URLSearchParams
Methoden werden dieser Tatsache gerecht!
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.
Es geht um einen Ersatz von jQuery.serialize. Und da ist FormData völlig fehl am Platze weil es weder
1. eine Datenstruktur für den Default Enctype lliefert
2. noch den Enctype selbst serialisiert
..anstatt eine universelle Struktur schaffen zu wollen, die sich anderweitig als nachteilig erweisen kann.
In Hinblick möglicher Erweiterungen auf Enctypes wie application/json
oder application/xml
ist ein Zwischenschritt über eine universelle Datenstruktur auf jeden Fall sinnvoll.
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.
Das kann man auch mit Methoden die das DOM bietet.
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.
Die von mir gezeigte Datenstruktur passt ebenso auch auf den Enctype application/x-www-form-urlencoded !
also dieda:
[ { name:.., value: .., }, {},{},, ]
MfG