Was dieses Werkzeug tut
Aus einer JSON-Probe werden JSDoc-Typedefs, ein Block je Objekt.
{ "id": 1, "name": "Ada", "address": { "city": "Paris" } }/**
* @typedef {Object} Root
* @property {number} id
* @property {string} name
* @property {Address} address
*/
/**
* @typedef {Object} Address
* @property {string} city
*/Setzen Sie sie an den Anfang einer .js-Datei, und jedes @type {Root} darin wird geprüft — vom Editor und von tsc --checkJs, wenn Sie es laufen lassen.
Auch eine Liste an der Wurzel wird benannt
/**
* @typedef {Array<UsersItem>} Users
*/Dieser Block fehlte: eine Array-Probe ergab allein das Typedef des Elements, und der eingestellte Wurzelname führte nirgendwohin. Ein echter Fehler, beim Schreiben dieser Seite gefunden und behoben.
Arrays werden stets Array<…> geschrieben, nicht …[]. Beides ist gültig; die lange Form bleibt lesbar, wenn der Elementtyp eine Union oder ein * ist.
Ein Schlüssel, der kein Bezeichner ist
{ "content-type": "text/html" } * @property {string} "content-type"Die Anführungszeichen halten den Schlüssel lesbar, und sie sind kein Standard-JSDoc: für einen Eigenschaftsnamen, der kein gültiger Bezeichner ist, gibt es keine Syntax. Das steht hier, statt verschwiegen zu werden: nichts in der Ausgabe warnt Sie, und ein Editor kann diese Zeile schlicht übergehen. Ein solcher Schlüssel wird am besten an der Quelle umbenannt.
Was eine Probe nicht entscheiden kann
Jede Eigenschaft wird als vorhanden dokumentiert, denn das zeigte das Dokument. JSDoc schreibt eine optionale @property {string} [name] und eine nullbare {?string} — beides Änderungen, die man mit Kenntnis der API vornimmt, keine Tatsachen aus einer einzigen Nutzlast.
Ein unbekannter Wert wird *, das „beliebiger Typ“ von JSDoc. Es erscheint dort, wo die Probe schweigt: ein leeres Array ergibt Array<*>.
Datenschutz ab Werk
Alles läuft lokal in deinem Browser mit JavaScript. Deine Daten werden nie hochgeladen, wodurch das Tool auch für sensible Inhalte sicher ist und offline funktioniert.