-
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
Conversation
✅ Deploy Preview for dashboard-v2-novu-staging ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for dev-web-novu ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
@novu/client
@novu/headless
@novu/framework
@novu/node
@novu/notification-center
novu
@novu/providers
@novu/shared
commit: |
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! :)
left a couple of comments for your review.
apps/api/src/app/workflows-v2/mappers/notification-template-mapper.ts
Outdated
Show resolved
Hide resolved
@@ -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 comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we should keep the mapping here for two key reasons:
- We’re adding extra parameters, such as
slug
, which are only exposed to the API client. - We’re mapping the types—for instance, if the entity allows
undefined
, we convert those to stricter types in the DTO response.
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 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 comment
The 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 BuildStepDataUsecase
.
The return type from the BuildStepDataUsecase
doesn't allow undefined and does explicit checks for missing values, therefore having additional response type for step and mapping, e.g. like this:
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.
apps/api/src/app/workflows-v2/usecases/get-workflow/get-workflow.usecase.ts
Outdated
Show resolved
Hide resolved
@@ -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( |
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
apps/api/src/app/workflows-v2/usecases/get-workflow/get-workflow.usecase.ts
Show resolved
Hide resolved
apps/api/src/app/workflows-v2/usecases/sync-to-environment/sync-to-environment.usecase.ts
Outdated
Show resolved
Hide resolved
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's looking OK, I'm missing some tests and added some comments, lets please resolve / reply to them before merging
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; | ||
} |
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.
I moved this directly to the build-step-data
use-case, because its always used together with the use-case.
If the usecase for unsanitized step data emerges, then we can split it again or create GetStepDataInternal
usecase.
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.
What changed? Why was the change needed?
TL;DR:
GET step
andGET workflow
endpoints💡 These changes do not affect FE-BE compatibility in any way - only new fields were added to
workflow.steps
, no external DTO property was removed or renamed.Key DTO changes:
File renames and moves:
step-data.dto
➔step.dto.ts
(better reflects contents and avoids circular imports).step.dto.ts
.workflow.dto.ts
➔workflow.deprecated.dto
(contains only deprecated DTOs).workflow-response.dto
➔workflow.dto.ts
.workflow.dto.ts
.Simplified Step DTO:
StepResponseDto
withStepDataDto
(already used by GET step).Refactoring:
sync-to-environment.usecase
- improved naming, less code, clearer intentNext steps:
GET workflow
endpoint.1.1 this will enable us to get rid of react-query cache invalidation code, step hooks etc
GET step
endpoint, (I think we should also removePATCH step
+ usecases) since we are currently not using them - if we decide to use them again in future we can find them in git history