Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi there! 👋 I stumbled upon that case 2 or 3 times and decide to give it a shot to solve my problem and most likely help some other great folks as well 😄
I've read the hints from #202, extended
ModelValueType
, adjusted the generation of nested object values within nullable nested objects and also adjusted types here and there to properly handle nullable nested objects.Sharing some context behind technical decisions/changes I've made:
isGetterFunctionReturningObject
toNullableProperty
- it indicates if we should generate properties for nested nullable objects insrc/model/parseModelDefinition.ts
. It's needed when we have some getter function returning object with nested properties in factory and we're not providing any value for these nested object properties during model creation (case is covered innullable object property > when object getter is provided in factory definition > defaults to value provided in factory when not set during model creation
test)getDefinition
function to "unwrap" the getter value fromNullableProperty
when we want to get the default values of nested properties within nullable object propertiesValue
inglossary.ts
to properly infer types in case of some object is passed as generic type. It was also needed to makenulllable<Date>(() => null)
to work properly (you can find some examples intest/query/date.test.ts
)src/query/queryTypes.ts
were required when querying dates withlte
/gte
(case is covered inignores entities with missing values when querying using date
test)I tried to provide API without a getter function (as mentioned in #203), however I failed on providing proper typing for it (some raw PoC can be found in roertbb#1). Recently, decided to neglect that idea and try out extending existing
NullableProperty
(which is using getter function) to incorporate objects there.Working on that one was a pretty good journey into depths of
mswjs/data
, I think I understood quite some of them, but I still may be missing some other parts - I'd be really grateful for guidance on what I could've missed or how I could make it more elegant and readable 😉I also wrote couple of tests that served me as a test cases. These are not extensively testing all the possible use-cases, but should be a good foundation. If you have other test-cases on your mind, if you feel that it will be more readable to structure tests some other way - please share some feedback 😉
Resolves #203