J'ai un certain nombre de plugins JQuery que je voudrais charger avec le motif AMD dans Typecript. Par exemple, je pourrais avoir cette structure:
define(["require", "exports", "lib/jquery.myplugin"], function (require, exports, __jquery.myplugin__) { ... // Use my plugin $('#my-element').myExample(); }
3 Réponses :
genre de hack, mais voici la seule façon dont je connais actuellement.
myplugin.d.ts em>: étend l'interface jQueryStatique pour inclure Intellisense pour la fonctionnalité de MyPlugin P> define(["require", "exports", 'myplugin'], function(require, exports, __myplugin__) {
/// <reference path="myplugin.d.ts" />
var myplugin = __myplugin__;
// without this typescript knows you aren't actually using the module
// and won't create the define block including your plugin
var workaround = myplugin.test;
$.myFunc();
})
Il semble que vous deviez également définir un chemin dans la configuration requisjs (ou quel que soit votre chargeur AMD que vous utilisez) qui associe «myplugin» avec le chemin du plugin, correct? Sinon, si vous mettez MyPlugin.d.ts au même endroit que le plugin, le fichier JS compilé écrasera votre bibliothèque de plug-in.
Ce n'est que si vous avez exécuté le compilateur avec le drapeau des définitions et ne spécifiait pas un répertoire de sortie alternatif. Il suffira de générer MyPlugin.js par défaut.
Je dis que MyPlugin.js est probablement le nom de votre bibliothèque dans ce cas. Dans mon exemple, j'aurais importé «lib / jquery.myplugin». Donc, sans aliaser le nom de dépendance, votre fichier JavaScript généré remplacera votre bibliothèque.
@dcstraw Il ne écrasera pas votre bibliothèque car elle créera un fichier nommé myplugin.d.js code> pas
myplugin.js code>.
@Sohnee je n'ai jamais vu TSC générer un fichier .d.js. Il n'y a pas de sortie pour un fichier .D.TS et un fichier .TS génère un fichier .js.
Je vois ce que tu veux dire. Oui j'ai un problème similaire comme celui-ci sans solution encore aussi
@DCStraw Si vous utilisez Visual Studio, il y aura un fichier d.js code>, mais il n'est jamais utilisé.
Au bas du fichier que l'interface est définie dans vous, vous pouvez mettre: qui rendra l'intellistenense for jQuery apparaître sur n'importe quel fichier chargé à l'aide de Votre fichier est chargé de manière asynchrone et vous définissez jQuery strong> à une autre variable (c'est-à-dire myjQuery strong>), vous pouvez déclarer que le Le fichier a déjà été chargé par un certain point, par exemple, si vous avez le fichier dans votre pour rendre votre myjQuery strong> de type jQuery strud>. p> Un autre hack est d'insérer l'interface directement dans la zone Lorsque le code est chargé de manière asynchrone: p> Si cela ne vous dérange pas de modifier vos fichiers jQuery.d.ts, vous pouvez ajouter votre fonction aux interfaces définies dans ce document. p> Retour à votre exemple, vous devriez pouvoir faire quelque chose comme: p> en haut de votre rappel défini; et à condition que vous ayez étendu l'interface pour Import Module < /code.com.
//////////dibe = ...> code> Vous devriez pouvoir utiliser: p> < Pré> xxx pré>
///
Je n'ai pas utilisé Amd moi-même, mais j'espère que cela vous aide!
La déclaration de variables globales fonctionne bien pour les bibliothèques que vous chargez à travers d'autres moyens, ex. une étiquette de script dans votre HTML. L'avantage du modèle AMD est que cela vous permet de déclarer votre dépendance et de le faire charger selon les besoins ou regroupés au moment de la construction, et votre espace de noms global ne doit pas être pollué. Ceci est spécifiquement ce qui n'est pas bien pris en charge dans TypeScript pour les bibliothèques sans exportation de niveau supérieur.
Je suis désolé, je pensais que le modèle AMD ait travaillé d'un style de rappel? Si oui, alors ne serait-il pas possible de déclarer une variable avec l'interface JQuery dans le rappel? Ensuite, cela apparaîtrait à IntelliSense que dans le rappel et non dans le reste du dossier.
La question n'est pas avec les capacités du motif AMD, mais avec l'intégration de TickyScript entre les modules et le motif AMD. Il n'y a aucun moyen de créer le compilateur dossier générer le bon définir l'appel code> à l'aide de modules dans la mise en œuvre actuelle.
OK, je comprends. Vous vouliez générer la fonction définir code> tout le long. Je pensais que vous vouliez juste que vous vouliez
intellisense code> pour toutes les variables déclarées dans la liste des paramètres de votre rappel. Pardon! :)
TypeScript n'importera pas les modules à moins d'exporter quelque chose et que si vous n'utilisez directement ce qu'ils ont exporté, mais ces choses ne sont pas vraies pour des plugins de JQuery qui ajoutent simplement de nouvelles méthodes à $. La solution consiste à utiliser le drapeau de dépendance AMD comme documenté ici .
Ajoutez une ligne comme celle-ci en haut de votre fichier: p> ceci va forcer dockscript à la liste dans le < Code> Définir l'invocation code> dans le JavaScript compilé. Vous aurez également besoin de configurer un chemin et une cale pour votre plugin dans votre requête.Config, comme celui-ci: p>
Excellent merci beaucoup. Je ne pense pas que cette fonctionnalité existait quand j'ai posé la question. Cela ressemble exactement à ce que je cherchais.
Ma solution de contournement actuelle est d'appeler manuellement
exiger ([...], () => {...}) code> dans mon code dossier, qui génère un appel requis imbriqué. Loin de l'idéal, mais ça marche.