[🚀 Feature]: [dotnet] [bidi] Consider command optional arguments as optional method arguments

[nvborisenko]

Description

Now:

await context.NavigateAsync("https://selenium.dev");

Even with optional arguments:

await context.NavigateAsync("https://selenium.dev", new() { Wait = ReadinessState.Complete});

It is very good API to prevent any breaking changes if BiDi Spec changes optional parameters.

Have you considered any alternatives or workarounds?

What if we consider C# optional arguments natively?

await context.NavigateAsync("https://selenium.dev", wait: ReadinessState.Complete);

[selenium-ci]

@nvborisenko, thank you for creating this issue. We will troubleshoot it as soon as we can.

Selenium Triage Team: remember to follow the Triage Guide

[nvborisenko]

Having optional method arguments is bad for libraries. But Selenium library mimics BiDi specification.

If BiDi Spec is stable, then C# optional arguments looks good? The question is how stable spec is..

[nvborisenko]

It is very good proposal.

Solution

Use source generation for alternative methods. With a remark in xml docs that this alternative API is "dangerous".

Any thoughts?

CC: @YevgeniyShunevych @RenderMichael

[RenderMichael]

We can make the options parameter optional, so the default experience can look like the proposed simplification while maintaining extensibility if the spec changes.

public Task NavigateAsync(string url, NavigationOptions? options = null);

[nvborisenko]

@RenderMichael Mike, it is already available as you wrote. The question is if NavigationOptions consists of many more params?

class NavigationOptions
{
  string A {};
  string B {};
}

Then do we want to:

public Task NavigateAsync(string url, string a = null, string b = null);