-
-
Notifications
You must be signed in to change notification settings - Fork 720
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: playground custom properties are nested #4686
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Ignored Deployment
|
@@ -58,7 +61,10 @@ export const PlaygroundCodeFieldset: VFC<IPlaygroundCodeFieldsetProps> = ({ | |||
try { | |||
const contextValue = JSON.parse(input); | |||
|
|||
setFieldExist(contextValue[contextField] !== undefined); | |||
setFieldExist( | |||
contextValue[contextField] !== undefined || |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we need to also check nested properties now
setContext( | ||
JSON.stringify( | ||
{ | ||
normalizeCustomContextProperties({ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is where we fix the user input
@@ -1,14 +1,19 @@ | |||
type Dict<T> = { [K in keyof T]: string[] }; | |||
type Dict<T> = { [K in keyof T]: (string | number)[] }; | |||
|
|||
export const splitByComma = <T extends Record<string, unknown>>( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it had to change to support nested properties
sessionId: '1,2', | ||
nonString: 2, | ||
properties: { | ||
nonString: 1, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
properly nested custom properties take precedence
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me 😄 One question though: what happens if you provide a custom property (in the properties object) with the same name as one of the standard properties?
For instance:
appName: "top-level:
properties: {
appName: "nested"
}
I know that we can do that with SDKs today, so the SDK handling should be standardized (I hope? 🤔), but is it in line with how you flatten it for the return? What would this be returned as?
appName: "top-level"
or
appName: "nested"
@thomasheartman raised a slack discussion about it. Currently custom properties always win. |
About the changes
Properties in playground should be copy-paste friendly for the SDK. That's why custom properties are added in nested properties as in the SDKs. The auto-formatting/normalization works when we're adding values with add/replace button.
Important files
Discussion points
Backend code can generate context field combinations on flat and nested property fields. So our input is more forgiving now. The API response stays the same for now with a flat list of properties since I don't want to change the UI table results.
So even if you send
In the response you get