Conversation
There was a problem hiding this comment.
Pull request overview
This PR refactors the FmtOptions parameter from a generic Dictionary<string, string> to a strongly-typed FmtOptions class, improving type safety and API clarity.
Changes:
- Introduced a new
FmtOptionsclass with explicitly typed properties for all format options - Updated request models to use the new
FmtOptionstype instead ofDictionary<string, string> - Modified URL building logic in
Helpers.csto handle the strongly-typedFmtOptionsobject with separate handling for scalar and array properties
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
| src/constructor.io/models/common/FmtOptions.cs | New strongly-typed class defining all format option properties with documentation |
| src/constructor.io/utils/Helpers.cs | Updated URL building to serialize FmtOptions properties individually with new helper methods |
| src/constructor.io/models/common/IPlpRequest.cs | Changed FmtOptions property type from dictionary to typed class |
| src/constructor.io/models/Search/SearchRequest.cs | Updated FmtOptions property type to use new class |
| src/constructor.io/models/Browse/BrowseRequest.cs | Updated FmtOptions property type to use new class |
| src/constructor.io/models/Browse/BrowseItemsRequest.cs | Updated FmtOptions property type to use new class |
| src/constructor.io/models/Browse/BrowseFacetsRequest.cs | Refactored to use strongly-typed FmtOptions with null-coalescing initialization |
| src/constructor.io/models/Browse/BrowseFacetOptionsRequest.cs | Refactored to use strongly-typed FmtOptions with null-coalescing initialization |
| src/Constructorio_NET.Tests/utils/HelpersTest.cs | Added comprehensive tests for new FmtOptions serialization including array handling |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Alexey-Pavlov
left a comment
There was a problem hiding this comment.
Looks great, thanks so much! I’ve left a few comments—when you get a moment, could you take a look?
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Alexey-Pavlov
left a comment
There was a problem hiding this comment.
Thank you for making changes! LGTM!
* Add rex support * Update src/Constructorio_NET.Tests/client/modules/RecommendationsTests.cs Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Update tests * Fix flaky test --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 20 out of 20 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Add quiz answers to query string | ||
| if (queryParams.Contains(Constants.ANSWERS)) | ||
| { |
There was a problem hiding this comment.
MakeUrl no longer has a dedicated branch for Constants.FMT_OPTIONS / Constants.HIDDEN_FIELDS / Constants.HIDDEN_FACETS. If any caller still passes the legacy shapes (e.g., FMT_OPTIONS as Dictionary<string,string>), those entries will now be silently ignored (no query string output) because the "remaining query params" loop only handles string, int, List<string>, and bool. Consider either keeping backward-compatible serialization for these keys or explicitly throwing a clear exception when legacy keys are present so the failure mode isn’t silent.
There was a problem hiding this comment.
LGTM, just one comment. @Alexey-Pavlov mind taking a second look?
| if (res.Response.Results.Count > 0) | ||
| { | ||
| var metadata = res.Response.Results[0].Data?.Metadata; | ||
| Assert.IsNotNull(metadata, "Result metadata exists"); | ||
| Assert.IsTrue( | ||
| metadata.ContainsKey(requestedHiddenField), | ||
| "Requested hidden field is present in result metadata" | ||
| ); | ||
| Assert.IsNotNull( | ||
| metadata[requestedHiddenField], | ||
| "Requested hidden field has a non-null value in result metadata" | ||
| ); | ||
| } |
There was a problem hiding this comment.
Should we throw an error if results.Count = 0? If it's ever zero, and this functionality breaks, we wouldn't be aware.
Alexey-Pavlov
left a comment
There was a problem hiding this comment.
LGTM! Thank you! Left some minor comments
This is a breaking change. Please do not merge until we land on a release strategy.