-
-
Notifications
You must be signed in to change notification settings - Fork 664
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
feat: playground api returns removed context values under a new `warn…
…ings` property (#6784) This PR expands upon #6773 by returning the list of removed properties in the API response. To achieve this, I added a new top-level `warnings` key to the API response and added an `invalidContextProperties` property under it. This is a list with the keys that were removed. ## Discussion points **Should we return the type of each removed key's value?** We could expand upon this by also returning the type that was considered invalid for the property, e.g. `invalidProp: 'object'`. This would give us more information that we could display to the user. However, I'm not sure it's useful? We already return the input as-is, so you can always cross-check. And the only type we allow for non-`properties` top-level properties is `string`. Does it give any useful info? I think if we want to display this in the UI, we might be better off cross-referencing with the input? **Can properties be invalid for any other reason?** As far as I can tell, that's the only reason properties can be invalid for the context. OpenAPI will prevent you from using a type other than string for the context fields we have defined and does not let you add non-string properties to the `properties` object. So all we have to deal with are top-level properties. And as long as they are strings, then they should be valid. **Should we instead infer the diff when creating the model?** In this first approach, I've amended the `clean-context` function to also return the list of context fields it has removed. The downside to this approach is that we need to thread it through a few more hoops. Another approach would be to compare the input context with the context used to evaluate one of the features when we create the view model and derive the missing keys from that. This would probably work in 98 percent of cases. However, if your result contains no flags, then we can't calculate the diff. But maybe that's alright? It would likely be fewer lines of code (but might require additional testing), although picking an environment from feels hacky.
- Loading branch information
1 parent
6142e09
commit c59d28a
Showing
7 changed files
with
117 additions
and
28 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,16 +1,26 @@ | ||
import type { SdkContextSchema } from '../../openapi'; | ||
|
||
export const cleanContext = (context: SdkContextSchema): SdkContextSchema => { | ||
export const cleanContext = ( | ||
context: SdkContextSchema, | ||
): { context: SdkContextSchema; removedProperties: string[] } => { | ||
const { appName, ...otherContextFields } = context; | ||
const removedProperties: string[] = []; | ||
|
||
const cleanedContextFields = Object.fromEntries( | ||
Object.entries(otherContextFields).filter( | ||
([key, value]) => key === 'properties' || typeof value === 'string', | ||
), | ||
Object.entries(otherContextFields).filter(([key, value]) => { | ||
if (key === 'properties' || typeof value === 'string') { | ||
return true; | ||
} | ||
removedProperties.push(key); | ||
return false; | ||
}), | ||
); | ||
|
||
return { | ||
...cleanedContextFields, | ||
appName, | ||
context: { | ||
...cleanedContextFields, | ||
appName, | ||
}, | ||
removedProperties, | ||
}; | ||
}; |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters