Dr. Axel Rauschmayer befasst sich mit JSON-Modulen, die bereits in Chrome 91 (aber sonst nirgends) verfügbar sind. Es sieht aus wie ein Import im ES-Module-Stil, nur dass man den Typ am Ende angibt.
import configData from './config-data.json' assert {type: 'json'};Wie schön ist das denn? Sobald dies die Browser erreicht, sind wir von „Sie werden fast sicher eine Ajax-Bibliothek verwenden wollen", aufgrund der browserübergreifenden Komplexität und Merkwürdigkeit von XMLHttpRequest, zu der viel schöneren (aber Sie müssen immer noch etwas Code schreiben) fetch API, zu einer einzigen Zeile (wenn Sie JSON-Daten benötigen) gelangt.
Das Abrufen einiger JSON-Daten sollte meiner Meinung nach so einfach sein wie eine einzige Zeile, und jetzt ist es das auch. Ich mag es, dass die URL jetzt dynamisch sein kann.
Ich muss hier mehr lesen.
Warum braucht man
assert {type: 'json'}?Wir haben bereits den Typ aus der
.json-Erweiterung.Im Artikel, den ich verlinkt habe, beantwortet.
Ich weiß nicht, warum ich Chris' Kommentar nicht beantworten kann, also antworte ich hier.
„Sie schauen auf Content Types“, „Server sind dafür verantwortlich, diese bereitzustellen“. Warum muss ich sie dann definieren? :) Ich bin der Client, nicht der Server.
Allerdings schlugen in einer Issue Ryosuke Niwa (Apple) und Anne van Kesteren (Mozilla) vor, dass die Sicherheit verbessert würde, wenn ein syntaktischer Marker beim Importieren von JSON-Modulen und ähnlichen Modultypen, die keinen Code ausführen können, erforderlich wäre, um ein Szenario zu verhindern, in dem der antwortende Server unerwartet einen anderen MIME-Typ bereitstellt, was zur unerwarteten Ausführung von Code führen würde. Die Lösung bestand darin, irgendwo zusätzlich zum MIME-Typ anzugeben, dass ein Modul JSON ist oder im Allgemeinen nicht ausgeführt werden soll.
Einige Entwickler haben die Intuition, dass die Dateierweiterung verwendet werden könnte, um den Modultyp zu bestimmen, wie es in vielen bestehenden nicht standardmäßigen Modulsystemen der Fall ist. Es ist jedoch ein Grundprinzip der Webarchitektur, dass der Suffix einer URL (den man außerhalb des Webs als „Dateierweiterung“ betrachten könnte) keine Semantik dafür liefert, wie die Seite interpretiert wird. In der Praxis gibt es im Web einen weit verbreiteten Abgleich zwischen Dateierweiterung und dem HTTP Content Type Header. All dies führt dazu, dass es nicht praktikabel ist, sich auf Dateierweiterungen/Suffixe zu verlassen, die im Modulspezifizierer enthalten sind, als Grundlage für diese Überprüfung.
Können wir als nächstes HTML-Importe haben?
Leider scheint dieses Schiff bereits abgefahren zu sein.