Jsdom: Implémentations WebSocket prises en charge

Eh bien, si vous vous posez des questions sur l'intégration dans jsdom, mon vote irait à celui qui :

• est bien entretenu
• n'a pas de dépendances binaires
• implémente l'API par spécification

En particulier, ws n'implémente définitivement pas l'API de spécification, par exemple en utilisant on au lieu de addEventListener et ainsi de suite.

Je ne comprends pas très bien quel est le but de cette question. Vous préparez-vous à créer un PR pour ajouter la prise en charge des sockets Web à jsdom ?

Je créerais un PR pour ajouter le support Websocket si vous le souhaitez. Pour le code que je teste avec JSDom, je souhaite également pouvoir tester les websockets (tout en étant capable de tout parcourir en navigateur).

Ce serait adorable!

Serait-il approprié d'utiliser ws sous le capot, mais de faire en sorte que l'API corresponde à la spécification de l'API pour les Websockets ?

Absolument.

À quoi sert JSDom au XIe siècle s'il ne prend pas en charge les WebSockets ? ..
:-)
@rgbkrk +1
@domenic as-tu intégré le PR ?

@avesus Il s'avère que beaucoup de gens y trouvent un but jusqu'à présent, même s'il ne s'agit pas d'un navigateur complet.

avez-vous intégré le PR ?

Quelle RP ?

Je n'ai jamais fait de relations publiques, j'ai fini par m'éloigner un peu de jsdom ainsi que du projet pour lequel je voulais des websockets. Retour à l'utiliser à nouveau cependant!

Veuillez utiliser les boutons de vote et ne pas ajouter de commentaires « moi aussi ». Suppression de celui qui vient d'apparaître.

Boutons de vote ? Je cherche ça, j'ai trouvé une pétition de changement mais il semble que github n'ait implémenté aucun système de vote.

@davidworkman9

@inikulin merci. Je ne savais pas que dans github land cette réaction.signification == vote.signification (ou que vous pouviez utiliser les réactions comme mécanisme de vote). Désolé pour mon manque de compétences sociales github appropriées.

Hé c'est bon, la fonctionnalité n'existe que depuis quelques semaines IIRC.

quel est l'état actuel du websocket dans jsdom ?

Ce n'est pas mis en œuvre.

@Sebmaster
Il est très difficile de séparer le code des websockets. Nous aimerions tester les vues, mais les vues nécessitent des modèles, les modèles nécessitent des Websockets. Moking modèles est possible mais plage de test très proche.

Prévoyez-vous de mettre en œuvre des Websokets dans un avenir proche ?

Je pense que personne d'entre nous ne le met actuellement en œuvre ou n'en donne la priorité dans un avenir proche. Donc, à moins qu'il n'y ait un RP ou un changement de priorités, probablement pas.

Est-ce que quelqu'un est intéressé à collaborer sur cela?

Je suis prêt à faire le travail, mais ce serait formidable que d'autres participent au moins aux examens.

@palmerj3 Je serais intéressé, mais je suis sûr que le reste de @jsdom le serait aussi. Assurez-vous simplement de consulter les exigences @Joris-van-der-Wel répertoriées lors du choix d'une bibliothèque WS : https://github.com/tmpvar/jsdom/issues/1195#issuecomment-131390814. Si vous rencontrez des problèmes, nous serons sur #jsdom chez Freenode pour vous aider :)

Est-ce que quelqu'un travaille là-dessus ? Je vais tenter le coup sinon

Personne ne travaille là-dessus. ws prend en charge addEventListener maintenant , vous devriez donc pouvoir utiliser ce module directement.

En général, nous ne pouvons utiliser aucun module directement car ils ne prennent pas en charge la sémantique Web IDL complète ; l'emballage sera toujours nécessaire. Voir https://github.com/tmpvar/jsdom/blob/master/Contributing.md#architecture pour plus d'informations.

L'utiliser ne fonctionnerait-il pas ? https://www.npmjs.com/package/universal-websocket-client

C'est en fait ce que j'utilise dans mon application avec laquelle jsdom a des problèmes

Ce ne serait certainement pas une bonne idée ; c'est juste un wrapper autour de ws , nous aurions donc besoin d'un wrapper autour d'un wrapper autour de ws. Faisons juste une couche d'emballage, s'il vous plaît.

AFAIK, ce wrapper implémente cette API de spécification

Oui, mais comme j'ai essayé de l'expliquer (et Contributing.md l'explique plus en détail), il ne l'implémente pas d'une manière compatible avec les systèmes de jsdom. Par exemple, jsdom contient déjà un EventTarget, nous ne pouvons donc pas utiliser celui fourni avec ws (ou universal-websocket-client); alors nous aurions des doublons.

Ah ça a du sens. Je vais creuser dans les documents de contribution. Merci

Merci @domenic et @thdxr.

Pour info, il existe maintenant un PR actif mettant en œuvre l'intégralité des API WebSocket, dans https://github.com/tmpvar/jsdom/pull/2088. Vérifie s'il te plaît!

L'API WebSocket PR vient d'être fusionnée ! Le support sera disponible dans la prochaine version de jsdom.