-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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(api): add full step data to workflow dto; refactor #7235
Changes from 2 commits
d829484
546801d
0302cd8
01e4a62
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,7 +2,7 @@ import { | |
PreferencesResponseDto, | ||
RuntimeIssue, | ||
ShortIsPrefixEnum, | ||
StepResponseDto, | ||
StepDataDto, | ||
StepTypeEnum, | ||
WorkflowCreateAndUpdateKeys, | ||
WorkflowListResponseDto, | ||
|
@@ -15,7 +15,10 @@ import { NotificationStepEntity, NotificationTemplateEntity } from '@novu/dal'; | |
import { WorkflowInternalResponseDto } from '@novu/application-generic'; | ||
import { buildSlug } from '../../shared/helpers/build-slug'; | ||
|
||
export function toResponseWorkflowDto(workflow: WorkflowInternalResponseDto): WorkflowResponseDto { | ||
export function toResponseWorkflowDto( | ||
workflow: WorkflowInternalResponseDto, | ||
fullSteps: StepDataDto[] | ||
ChmaraX marked this conversation as resolved.
Show resolved
Hide resolved
|
||
): WorkflowResponseDto { | ||
const preferencesDto: PreferencesResponseDto = { | ||
user: workflow.userPreferences, | ||
default: workflow.defaultPreferences, | ||
|
@@ -30,7 +33,7 @@ export function toResponseWorkflowDto(workflow: WorkflowInternalResponseDto): Wo | |
tags: workflow.tags, | ||
active: workflow.active, | ||
preferences: preferencesDto, | ||
steps: getSteps(workflow), | ||
steps: fullSteps, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I believe we should keep the mapping here for two key reasons:
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. the first point is not relevant, i see that you added the slug to the BuildStepDataUsecase. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see your point but the stricter types in this case are already coming from the The return type from the name: step.name || 'Missing step name' would be redundant . I think we should keep it simple and when the usecase emerges then we can have some mapping. |
||
description: workflow.description, | ||
origin: computeOrigin(workflow), | ||
updatedAt: workflow.updatedAt || 'Missing Updated At', | ||
|
@@ -40,16 +43,6 @@ export function toResponseWorkflowDto(workflow: WorkflowInternalResponseDto): Wo | |
}; | ||
} | ||
|
||
function getSteps(template: NotificationTemplateEntity) { | ||
const steps: StepResponseDto[] = []; | ||
for (const step of template.steps) { | ||
const stepResponseDto = toStepResponseDto(step); | ||
steps.push(stepResponseDto); | ||
} | ||
|
||
return steps; | ||
} | ||
|
||
function toMinifiedWorkflowDto(template: NotificationTemplateEntity): WorkflowListResponseDto { | ||
const workflowName = template.name || 'Missing Name'; | ||
|
||
|
@@ -71,19 +64,6 @@ export function toWorkflowsMinifiedDtos(templates: NotificationTemplateEntity[]) | |
return templates.map(toMinifiedWorkflowDto); | ||
} | ||
|
||
function toStepResponseDto(persistedStep: NotificationStepEntity): StepResponseDto { | ||
const stepName = persistedStep.name || 'Missing Name'; | ||
|
||
return { | ||
_id: persistedStep._templateId, | ||
slug: buildSlug(stepName, ShortIsPrefixEnum.STEP, persistedStep._templateId), | ||
name: stepName, | ||
stepId: persistedStep.stepId || 'Missing Step Id', | ||
type: persistedStep.template?.type || StepTypeEnum.EMAIL, | ||
issues: persistedStep.issues, | ||
} satisfies StepResponseDto; | ||
} | ||
Comment on lines
-74
to
-85
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I moved this directly to the If the usecase for unsanitized step data emerges, then we can split it again or create Now I don't think its even possible to create step without name or stepId or without type, it seems to be here only because of tests. These things should be validated upon creation and not rely on fallbacks anyway. |
||
|
||
function buildStepTypeOverview(step: NotificationStepEntity): StepTypeEnum | undefined { | ||
return step.template?.type; | ||
} | ||
|
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.
the point was letting this map to dto, if you send the DTO pre cooked I think it's taking the string out of the funciton no? I would expect to get the entity list and maps of the additinoal data you want to bake in
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 still maps the workflow to DTO as name of the method suggests, only the steps are coming in already in "DTO form".
We simply don't need to do any mapping for the steps for now, its already in viable form, which is good. Each layer of mapping just adds an overhead