allow responsechema as example #608
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| script({ | ||
| responseType: "json_object", | ||
| responseSchema: { name: "neo", age: 30 }, | ||
| }) |
There was a problem hiding this comment.
Consider adding a description for the responseSchema example to clarify its purpose and usage.
generated by pr-docs-review-commit
example_schema
|
From the GIT_DIFF, it appears that the changes primarily deal with JSON schema handling and validation for chat responses and prompt templates in TypeScript. The changes include:
My concern is, while the changes seem to handle object types in the parameters, the code appears to implicitly assume that these objects will always be valid JSON schemas. This could potentially lead to errors if an object is passed that doesn't conform to a valid JSON schema. It would be good to include some form of validation or error handling for this scenario. Other than that, LGTM 🚀
|
| responseSchema: { name: "neo", age: 30 }, | ||
| }) | ||
| ``` | ||
|
|
There was a problem hiding this comment.
The documentation has been updated to include an example of how to generate a schema using an object example in the responseSchema field. Ensure that this addition is consistent with the rest of the documentation and that the example provided is clear and accurate.
generated by pr-docs-review-commit
documentation_update
pelikhan
changed the title
| t.type !== "array" && | ||
| t.default !== undefined | ||
| ) | ||
| res[key] = t.default |
There was a problem hiding this comment.
Default values for object and array types are not handled in the parsePromptParameters function. This could lead to unexpected behavior when these types are used in the parameters schema.
generated by pr-review-commit
object_default
| t.default !== undefined && | ||
| t.default !== null | ||
| ) | ||
| res.required.push(k) |
There was a problem hiding this comment.
The condition for adding a field to the required array in the promptParametersSchemaToJSONSchema function excludes object and array types. This could lead to these types being unexpectedly optional in the resulting schema.
generated by pr-review-commit
required_field
| if (typeof s === "string") return s | ||
| else if (typeof s === "number") return s.toLocaleString() | ||
| else if (typeof s === "boolean") return s ? "true" : "false" | ||
| else if (typeof s === "object") throw new Error("object not supported") |
There was a problem hiding this comment.
The normalizeString function throws an error when an object is passed. This could lead to unexpected crashes when objects are used in the parameters.
generated by pr-review-commit
object_normalization
| else if (t?.type === "boolean") | ||
| res[key] = /^\s*(y|yes|true|ok)\s*$/i.test(vars[key]) | ||
| res[key] = /^\s*(y|yes|true|ok)\s*$/i.test(vars[key] + "") | ||
| else if (t?.type === "string") res[key] = vars[key] |
There was a problem hiding this comment.
Parsing for object and array types is not handled in the parsePromptParameters function. This could lead to incorrect parsing when these types are used in the parameters schema.
generated by pr-review-commit
object_parse
| if (typeof s === "string") return s | ||
| else if (typeof s === "number") return s.toLocaleString() | ||
| else if (typeof s === "boolean") return s ? "true" : "false" | ||
| else if (typeof s === "object") throw new Error("object not supported") |
There was a problem hiding this comment.
The normalizeString, normalizeFloat, and normalizeInt functions throw an error when an object is passed. This could lead to unexpected errors when these functions are used with object values.
generated by pr-review-commit
object_normalize
| else if (t?.type === "boolean") | ||
| res[key] = /^\s*(y|yes|true|ok)\s*$/i.test(vars[key]) | ||
| res[key] = /^\s*(y|yes|true|ok)\s*$/i.test(vars[key] + "") | ||
| else if (t?.type === "string") res[key] = vars[key] |
There was a problem hiding this comment.
Default values for object and array types are not handled properly. This could lead to unexpected behavior when these types are used in the parameters.
generated by pr-review-commit
object_default
| if (typeof s === "string") return s | ||
| else if (typeof s === "number") return s.toLocaleString() | ||
| else if (typeof s === "boolean") return s ? "true" : "false" | ||
| else if (typeof s === "object") throw new Error("object not supported") | ||
| else return undefined |
There was a problem hiding this comment.
The normalizeString, normalizeFloat, and normalizeInt functions throw an error when an object is passed. This could lead to unexpected crashes if objects are used as parameters.
generated by pr-review-commit
object_not_supported
| promptParameterTypeToJSONSchema(v), | ||
| ]) | ||
| ), | ||
| } |
There was a problem hiding this comment.
The handling of objects in the promptParameterTypeToJSONSchema function could be improved. Currently, it assumes that all objects are of type object and it does not handle nested objects or arrays. This could lead to incorrect schema generation for complex objects.
generated by pr-review-commit
object_handling
| responseSchema: { characters: [{ name: "neo", age: 30 }] }, | ||
| }) | ||
| ``` | ||
|
|
There was a problem hiding this comment.
The example provided for generating a schema is incorrect. The responseSchema should define the schema structure with type, properties, and required fields, not an instance of the object.
generated by pr-docs-review-commit
schema_example_incorrect
| t.type !== "array" && | ||
| t.default !== undefined | ||
| ) | ||
| res[key] = t.default |
There was a problem hiding this comment.
The handling of default values in the parsePromptParameters function could be improved. Currently, it only sets default values for non-object and non-array types. This could lead to missing default values for nested properties in objects or arrays.
generated by pr-review-commit
default_handling
| @@ -212,28 +212,31 @@ export function groupBy<T>( | |||
| return r | |||
| } | |||
|
|
|||
| export function normalizeString(s: string | number | boolean): string { | |||
| export function normalizeString(s: string | number | boolean | object): string { | |||
There was a problem hiding this comment.
The normalizeString function in util.ts throws an error when the input is an object. This could lead to unexpected errors if the function is used with object inputs. Consider adding support for object inputs or clearly documenting this limitation.
generated by pr-review-commit
normalize_string
The
PromptParameterTypetype definition now supports object types. This enables complex parameter structures like nested objects and arrays. Your API has leveled up! 🎉The
responseSchemaproperty inModelOptionscan now acceptPromptParametersSchemaorJSONSchemaObject. This allows users to define the response structure at a higher level. More freedom for you! 🦅Added a new function
promptParametersSchemaToJSONSchemato convert aPromptParametersSchemato aJSONSchema. This function is now used in various parts of the codebase, wherever aJSONSchemawas needed from parameters. Stay DRY! 💦In the functions
applyRepairsandstructurifyChatSession, theresponseSchemais now converted to aJSONSchemabefore being passed to thevalidateJSONWithSchemafunction. 🔐The
callExpanderfunction has been updated to useresponseSchemain itsJSONSchemaObjectform. This way, it uses the high-level schema defined in templates. Consistency is key! 🔑Updated the
toStrictJSONSchemafunction to convertPromptParametersSchematoJSONSchemabefore applying transformations. This ensures the schema is always treated in its JSON form.🔄There has been a modification in the file
json_object_ex.genai.mjs, specifying a newresponseSchemaformat that includes complex nested objects. 📁Overall, these changes provide better utility to users, allowing them to use more complex and nested parameters and schemas. The codebase is also more DRY and consistent as higher level schemas are always transformed to
JSONSchemabefore use. Amazing upgrades! 🥳