2017-06-21 5 views
0

Wir verwenden Webstorm und JSDoc für einige nette Vorschlagsfunktionen und zur Typdokumentation bei Bedarf.JSDoc - Typdefinition mit Teilerstellung

Zum Beispiel ist dies die Definition von Benutzer, die mehrfach in der App verwendet wird.

/** 
    * Basic user object 
    * @typedef {Object} User 
    * @property {!Number} id - Unique identitifaction 
    * @property {!String} email - Email and username in once 
    * @property {!Boolean} enabled - True, if user can access the system 
    * @property {!Boolean} confirmed - True, if validation (i.e. through email) was successfull 
    * 
    * @property {?String} name - Name of user 
    */ 

Dann können wir ihn zum Beispiel in Dienstverfahren zum Auswählen von einigen Details der Benutzer verwenden

/** 
* return Detail of user 
* @param {User} params 
* @param {Options=} options 
* @returns Promise.<User> 
*/ 
exports.userDetail = (params, options = {}) => { 
    return userRepository.userDetail(params, options); 
}; 

Bei weitem funktioniert es wirklich toll, wenn ich params in exports.userDetail Methode verwenden, AutoSuggest es uns die Felder, die wir verwenden können, wenn wir wollen.

Das Problem ist "an der Spitze des Baumes". Zum Beispiel Standard CRUD Betrieb zum Detail ist dieses Verfahren verwendet und nur von id

/** 
* @param {Number} req.userId 
*/ 
exports.detail = (req, res, next) => { 
    return userService.userDetail({id: req.userId}).then(user => { 
     res.out = user; 
     return next(); 
    }).catch(next); 
}; 

jedoch in diesem Teil {id: req.userId} WebStorm ruft einen Fehler Auswahl: ‚Argument Typen ... ist nicht belegbar Typ Benutzer in den Parametern‘

Die einzige Lösung ist, ALLE Eigenschaften zu nennen, sonst sagt es das. Für andere Fälle ist diese Warnung sehr hilfreich - sie findet heraus, ob Sie Zahlen versehentlich in einen String oder einen ähnlichen Token in den Benutzer eingegeben haben. Jedoch macht das Mischen der echten Fehler diese weniger zuverlässig.

Jeder hat einige Tipps für JSDoc oder Webstorm im Allgemeinen? Ich habe keinen Weg gefunden, wie ich sagen kann "Dieser Parameter ist Benutzer auch ohne alle Felder, nicht alle sind Pflichtfelder".

Auf der anderen Seite möchte ich über die Anwendung ein Modell teilen - ich bei jeder Funktion vollständige Definition schreiben kann, die

/** 
* Register standard user 
* @param {String} _params.email Unique email for registration, used also instead of username 
* @param {String} _params.password Password for your account 
* @param {Options=} options 
*/ 

richtig funktioniert Aber wenn wir Benutzer in einer Menge o Methoden verwenden würde jede Änderung VIEL Arbeit bedeuten sie in der gesamten Anwendung zu aktualisieren

+0

nicht sicher, ob ich Ihnen folge ... Sie können versuchen, Ihre Eigenschaften als optional zu definieren - wie @property {String} [email] ' – lena

+0

@lena: Ja, es hat funktioniert, aus irgendeinem Grund weiß Webstorm {String =} optional für param aber nicht für Eigentum. Beantworte diese Frage mit [email] und ich werde dich akzeptieren :) – libik

Antwort

1

(fast unmöglich, wenn es groß genug wächst) Sie können versuchen, Ihre Eigenschaften als optional definieren - wie

/** 
    * Basic user object 
    * @typedef {Object} User 
    * @property {!Number} id - Unique identitifaction 
    * @property {!String} [email] - Email and username in once 
    * @property {!Boolean} [enabled] - True, if user can access the system 
    * @property {!Boolean} [confirmed] - True, if validation (i.e. through email) was successfull 
    * 
    * @property {?String} name - Name of user 
    */