Signalr: Paramètres facultatifs

Nous pouvons rendre la résolution des méthodes plus intelligente.

Certainement une bonne idée. J'ai commencé à travailler sur cela, mais je suis revenu pour pousser l'implémentation des hubs dynamiques de base dès que possible à ce moment-là.

En parlant de méthode de résolution ...
Avec l'implémentation actuelle, nous pourrions également ajouter la prise en charge des surcharges de méthode. La résolution de paramètres nommés serait également possible d'ajouter, mais cela impliquerait certaines modifications de la façon dont les paramètres sont réellement passés entre le client et le serveur (en passant des paires clé-valeur au lieu de seulement des valeurs). Que pensez-vous?

Cela s'applique-t-il également à un paramètre Nullable? J'ai une méthode avec 3 paramètres, dont le dernier est un int nullable (int?). Si je règle le dernier paramètre sur null, j'obtiens l'exception:

La valeur ne peut pas être nulle.
Nom du paramètre: o

à Newtonsoft.Json.Utilities.ValidationUtils.ArgumentNotNull (Object value, String parameterName)
à Newtonsoft.Json.Linq.JToken.FromObjectInternal (Object o, JsonSerializer jsonSerializer)
à Newtonsoft.Json.Linq.JToken.FromObject (Object o, JsonSerializer jsonSerializer)
sur Microsoft.AspNet.SignalR.Client.Hubs.HubProxy.Invoke T
à GeoTag.App.Core.Services.SignalRClientService.d__9.MoveNext ()

Notez que je n'ai pas défini de valeur par défaut pour celui-ci sur le serveur

Nous allons déplacer cela vers le nouveau repo en tant que candidat v3

@JasonBSteele - Je sais que cela fait un moment, mais le problème que vous mentionnez vient d'être résolu. Attendez-vous à le voir dans la prochaine version.

Je suis confus quant au statut de ce problème. A-t-il été corrigé dans une version de SignalR?

@paulirwin Non

...

Le correctif se trouve dans la version 2.2.1 expédiée en juillet (https://github.com/SignalR/SignalR/releases/tag/2.2.1)

J'ai retesté ce que j'ai rencontré hier, voici mes conclusions:
Méthode Hub que le client appellera

public async Task EpicMethod( int? daysTillNETStandard20 ) {}

Tentatives d'appel de méthode client-serveur .NET:

1. await _serviceRequestHubProxy.Invoke(nameof(ISomethingOnServerSide.EpicMethod), null).ConfigureAwait(false);

System.ArgumentNullException: Value cannot be null.
Parameter name: args
   at Microsoft.AspNet.SignalR.Client.Hubs.HubProxy.Invoke[TResult,TProgress](String method, Action`1 onProgress, Object[] args)
   at Microsoft.AspNet.SignalR.Client.Hubs.HubProxy.Invoke(String method, Object[] args)

2. await _serviceRequestHubProxy.Invoke(nameof(ISomethingOnServerSide.EpicMethod), null, null).ConfigureAwait(false);

System.InvalidOperationException: 'EpicMethod' method could not be resolved. Potential candidates are: 
EpicMethod(daysTillNETStandard20:Nullable`1):Task

3. await _serviceRequestHubProxy.Invoke(nameof(ISomethingOnServerSide.EpicMethod), null, new object[] {}).ConfigureAwait(false);

System.InvalidOperationException: 'EpicMethod' method could not be resolved. Potential candidates are: 
EpicMethod(daysTillNETStandard20:Nullable`1):Task
4. await _serviceRequestHubProxy.Invoke(nameof(ISomethingOnServerSide.EpicMethod), null, new object[] {null}).ConfigureAwait(false);
System.InvalidOperationException: 'EpicMethod' method could not be resolved. Potential candidates are: 
EpicMethod(daysTillNETStandard20:Nullable`1):Task

donc pour l'instant, j'ai supprimé la nullité de la méthode du hub et en passant 0 du côté client

Réouverture selon votre constatation ...

J'ai aussi ce problème. Sera résolu?

Cela ressemble à une simple question du classeur qui ne convertit pas null en Nullable<T> . Je vais enquêter.

Il s'avère donc que c'est en fait par conception. Comment vous devriez réellement passer un tableau d'objets avec la valeur null. Comme ça en utilisant votre exemple
await _serviceRequestHubProxy.Invoke(nameof(ISomethingOnServerSide.EpicMethod), new object[] {null}).ConfigureAwait(false);

Ce que vous faisiez était de définir le tableau de paramètres que le résolveur de paramètres utilisait sur null au lieu de passer une valeur null dans un tableau de paramètres.

Le problème est-il censé être résolu dans la version actuelle? Puisque la date d'émission était il y a 5 ans, mais les paramètres facultatifs ne fonctionnent toujours pas pour moi?

@AlameerAshraf - montrez exactement ce que vous essayez de faire. Je ne pense pas qu'il soit prévu de changer quoi que ce soit dans ce domaine à ce stade.

Je ne pense pas que les paramètres facultatifs fonctionnent comme prévu. Nous avons un appel sans paramètres, auquel je cherche à ajouter un paramètre.

Malheureusement, il n'y a aucun moyen de le faire sans rompre la compatibilité descendante, car notre code client appelle actuellement sans arguments, j'obtiens System.IO.InvalidDataException: Invocation fournit 0 argument (s) mais la cible en attend 1 - même avec un seul paramètre facultatif _nullable_.

Si je dois changer mon client pour passer un null, alors je ne peux pas maintenir la compatibilité descendante, et je peux aussi bien ne pas utiliser le paramètre facultatif du tout 😦

Solution de contournement: ajoutez et appelez une nouvelle méthode avec un nom différent, qui retourne à la méthode d'origine si aucun paramètre n'est passé. Décevant 👎

Je pense vraiment que les paramètres de méthode facultatifs et la surcharge devraient être pris en charge - cela pourrait être en retard car il est courant d'utiliser les deux et contre-intuitif de ne pas les utiliser lors de l'utilisation de SignalR.

Ici, en 2020, la surcharge de méthode fonctionne mais les paramètres facultatifs ne le font pas, de toute façon, je pense qu'il est toujours facile d'appeler simplement une méthode paramétrée à partir de non paramétrée et en gardant la compatibilité descendante.