-
Notifications
You must be signed in to change notification settings - Fork 0
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
chore: add support for multiple schemas within export/digitalPlanning
#629
Changes from 3 commits
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,8 @@ import { findPublishedFlowBySessionId } from "../../requests/flow.js"; | |
import { getSessionById, getSessionMetadata } from "../../requests/session.js"; | ||
import { ExportParams } from "../index.js"; | ||
import { DigitalPlanning } from "./model.js"; | ||
import { Application as DigitalPlanningPayload } from "./schema/types.js"; | ||
import { Application as ApplicationPayload } from "./schemas/application/types.js"; | ||
import { PreApplication as PreApplicationPayload } from "./schemas/preApplication/types.js"; | ||
|
||
interface DigitalPlanningExportParams extends ExportParams { | ||
skipValidation?: boolean; | ||
|
@@ -12,7 +13,9 @@ export async function generateDigitalPlanningPayload({ | |
client, | ||
sessionId, | ||
skipValidation, | ||
}: DigitalPlanningExportParams): Promise<DigitalPlanningPayload> { | ||
}: DigitalPlanningExportParams): Promise< | ||
ApplicationPayload | PreApplicationPayload | ||
> { | ||
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. In an ideal world, I think we'd have two separate classes that each return a precise type rather than a single class that returns As we move forward with the "prototypeApplication" and a top-level discriminated union, we know that bigger refactor is coming soon enough anyways - this is very much an interim working solution. 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. Agreed on general approach here for sure. If we hit any type issues with this in planx-new in the short term, we could maybe consider passing an additional argument into the class - type DigitalPlanningExportParams = {
client: Client;
sessionId: string;
skipValidation?: boolean;
type: "preApp" | ApplictionTypeUnion; // Create type discriminator here
};
export async function generateDigitalPlanningPayload({
client,
sessionId,
skipValidation,
type,
}: DigitalPlanningExportParams): Promise
// Modify return type based on this
type extends "preApp'"? PreApplicationPayload : ApplicationPayload
> {
...
} Returning a union though is exactly what I would have done here - I don't think we use the return type much in PlanX at this stage. 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. Appreciate you coming back to this one ! There's an explicit reason I haven't gone with an additional argument from the planx-new side which is the (admittedly awkward) reality that discretionary/undefined-application-type payloads are also getting routed through this function to create a generic "application.json" for submission payloads (send to email & S3). Therefore the discriminated type exposed to planx-new wouldn't be so tidy, but have to be something like this which felt pretty meaningless!
|
||
const session = await getSessionById(client, sessionId); | ||
if (!session) throw new Error(`Cannot find session ${sessionId}`); | ||
|
||
|
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'm generating two
types.d.ts
files now - one per schema - which makes sense for function return types, but does duplicate what the "source types" (eg digital-planning-data-schemas repo) know to be "shared" types. Now they're essentially just duplicated again