[dotnet] [bidi] Decouple EvaluateResult in Script module

[nvborisenko]

User description

Following spec https://w3c.github.io/webdriver-bidi/#type-script-EvaluateResult

I chose EvaluateResultSuccess instead of commonly used SuccessEvaluateResult, preferred the same in spec.

Motivation and Context

Contributes to #15407

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• I have read the contributing document.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.

---

PR Type

Enhancement

---

Description

• Replaced nested DTO types with standalone types for better extensibility.

• Updated EvaluateResult structure to use EvaluateResultSuccess and EvaluateResultException.

• Adjusted serialization and deserialization logic to align with new DTO structure.

• Refactored related methods and exception handling to use updated DTO types.

---

Changes walkthrough 📝

Relevant files

Enhancement

BiDiJsonSerializerContext.cs Updated JSON serialization for new DTO types                          dotnet/src/webdriver/BiDi/Communication/Json/BiDiJsonSerializerContext.cs Replaced nested DTO types with standalone types in JSON serialization. Updated references to EvaluateResultSuccess and EvaluateResultException. +2/-2      EvaluateResultConverter.cs Updated deserialization logic for new DTO types                    dotnet/src/webdriver/BiDi/Communication/Json/Converters/Polymorphic/EvaluateResultConverter.cs Adjusted deserialization logic to handle new standalone DTO types. Replaced nested type references with EvaluateResultSuccess and EvaluateResultException. +2/-2      BrowsingContextScriptModule.cs Refactored methods to use new DTO types                                    dotnet/src/webdriver/BiDi/Modules/BrowsingContext/BrowsingContextScriptModule.cs Updated method signatures to use EvaluateResultSuccess. Refactored calls to align with new DTO structure. +2/-2      EvaluateCommand.cs Refactored EvaluateCommand to use standalone DTOs                dotnet/src/webdriver/BiDi/Modules/Script/EvaluateCommand.cs Replaced nested EvaluateResult types with standalone EvaluateResultSuccess and EvaluateResultException. Updated implicit conversion logic for EvaluateResultSuccess. +8/-9      ScriptEvaluateException.cs Updated exception handling for new DTO structure                  dotnet/src/webdriver/BiDi/Modules/Script/ScriptEvaluateException.cs Updated exception handling to use EvaluateResultException. Replaced nested type references with standalone DTO type. +2/-2      ScriptModule.cs Refactored ScriptModule methods for new DTO types                dotnet/src/webdriver/BiDi/Modules/Script/ScriptModule.cs Refactored methods to use EvaluateResultSuccess and EvaluateResultException. Updated exception handling logic to align with new DTO structure. +6/-6

---

Need help?

Type /help how to ... in the comments thread for any questions about Qodo Merge usage.

Check out the documentation for more information.

[qodo-merge-pro]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis ✅ 15407 - Fully compliant Compliant requirements: Replace nested DTO types with standalone types Avoid using nested types that reserve names in the parent class Enable future extensibility for static factories and singletons

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Empty Record The PR introduces an empty record body for the abstract EvaluateResult class. This could be intentional, but it's worth verifying if this is the expected behavior or if there should be some common properties or methods. public abstract record EvaluateResult;

[qodo-merge-pro]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Learned best practice	Use TryGetProperty to safely check for JSON property existence before accessing it to prevent exceptions The code directly accesses the "type" property without checking if it exists first, which could throw a JsonException if the property is missing. Use TryGetProperty to safely check for the property's existence before accessing it. dotnet/src/webdriver/BiDi/Communication/Json/Converters/Polymorphic/EvaluateResultConverter.cs [34-39] -return jsonDocument.RootElement.GetProperty("type").ToString() switch +if (!jsonDocument.RootElement.TryGetProperty("type", out JsonElement typeElement)) + return null; + +return typeElement.GetString() switch { "success" => jsonDocument.Deserialize<EvaluateResultSuccess>(options), "exception" => jsonDocument.Deserialize<EvaluateResultException>(options), _ => null, }; Apply this suggestion Suggestion importance[1-10]: 6	Low
More

[RenderMichael]

These changes look good as part of the effort to remove nested DTOs.

In a future PR, we can change the EvaluateAsync/CallFunctionAsync to return EvaluateResult directly instead of throwing/returning success.