feat(api): poc preview usecase #7303
Conversation
✅ Deploy Preview for dev-web-novu ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for dashboard-v2-novu-staging ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| /* | ||
| * TODO: Consider if this validation is necessary since we already normalize in normalizeControlValues and, | ||
| * we can make it more robust by adding custom parsable by liquid js values | ||
| * | ||
| * Current purposes: | ||
| * 1. Validates control schema for code-first approach | ||
| * 2. Allows adding custom validation rules | ||
| * Example: If emailEditor is renamed to 'body', we can validate it's valid TipTap JSON | ||
| */ | ||
| if (controlSchema) { | ||
| const ajv = new Ajv({ allErrors: true }); | ||
| addFormats(ajv); | ||
|
|
||
| const validate = ajv.compile(controlSchema); | ||
| const isValid = validate(schemaCompliantControls); | ||
| const errors = validate.errors as null | ErrorObject[]; | ||
|
|
||
| if (!isValid && errors && errors?.length !== 0 && schemaCompliantControls) { | ||
| fixedValues = replaceInvalidControlValues(schemaCompliantControls, errors); | ||
|
|
||
| return { issues, schemaCompliantControls: fixedValues }; | ||
| } | ||
| } |
There was a problem hiding this comment.
this part, with the help of strict JSON schema/Zod, will work well for generating issues on context of type validation ("<param> required", <param> must be URL, etc...). However, in this context, I believe we can focus on improving normalizeControlValues to handle the heavy lifting. At this stage, the control values would then be clean and valid (aligned with the control schema and framework output schema), ensuring the preview runs smoothly.
| invalid: [...invalidVariables, ...invalidSchemaVariables], | ||
| }; | ||
|
|
||
| return resultVariables; |
There was a problem hiding this comment.
resultVariables.invalid will work well for generating issues based on the liquid errors (for example {{subscriber..firstName}} is invalid, etc...).
| // eslint-disable-next-line no-console | ||
| console.log('No template variables found'); |
There was a problem hiding this comment.
todo remove.
| invalidVariableExpression | ||
| ); | ||
|
|
||
| controlValuesString = replaceAll(controlValuesString, invalidVariable.template, liquidJsParsableString); |
There was a problem hiding this comment.
This part will filter out all non-parsable content (which would otherwise throw errors in Liquid JS) and replace it with the placeholder error message PREVIEW_ERROR_MESSAGE_PLACEHOLDER. Invalid output without {{ }} will also be handled (example [[Invalid Variable: subscriber.. email | upcase]]), ensuring the preview (in frameworks that use Liquid for parsing) doesn’t fail at runtime.
At this point, we have a single location where invalid "text" is identified. Now, we need to decide what to replace it with to provide the best possible UX. we could use an empty string here as well.
What changed? Why was the change needed?
Screenshots
Expand for optional sections
Related enterprise PR
Special notes for your reviewer