🏷️ [#445] Add TS type definitions for Form/Submission

[sergei-maertens]

This adds some of the type definitions for Form and Submission resources that we interact with from the v2 API endpoint(s), set up to strongly type the createSubmission function.

[codecov]

Bundle Report

Changes will increase total bundle size by 464 bytes (0.0%) ⬆️. This is within the configured threshold ✅

Detailed changes

Bundle name	Size	Change
@open-formulieren/sdk-OpenForms-umd	4.9MB	232 bytes (0.0%) ⬆️
@open-formulieren/sdk-esm	4.87MB	232 bytes (0.0%) ⬆️

Affected Assets, Files, and Routes:

view changes for bundle: @open-formulieren/sdk-esm

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
assets/sdk-*.js	232 bytes	1.02MB	0.02%

Files in assets/sdk-*.js:

• ./src/hooks/useFormContext.ts → Total Size: 66 bytes

• ./src/data/submissions.ts → Total Size: 726 bytes

• ./src/Context.ts → Total Size: 1.56kB

view changes for bundle: @open-formulieren/sdk-OpenForms-umd

Assets Changed:

Asset Name	Size Change	Total Size	Change (%)
open-*.js	232 bytes	3.53MB	0.01%

Files in open-*.js:

• ./src/Context.ts → Total Size: 1.56kB

• ./src/data/submissions.ts → Total Size: 726 bytes

• ./src/hooks/useFormContext.ts → Total Size: 66 bytes

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 83.52%. Comparing base (575138f) to head (bb36ea3).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #805      +/-   ##
==========================================
- Coverage   83.55%   83.52%   -0.03%     
==========================================
  Files         233      233              
  Lines        4633     4632       -1     
  Branches     1193     1193              
==========================================
- Hits         3871     3869       -2     
- Misses        732      733       +1     
  Partials       30       30              

Flag	Coverage Δ
storybook	76.88% <100.00%> (-0.01%)	⬇️
vitest	62.25% <100.00%> (-0.02%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[robinmolen]

Could we use something like https://www.npmjs.com/package/openapi-typescript for the API spec types? Otherwise i think updating the types will be a pain (and error-prone)..

[sergei-maertens]

I'm leaving out the bits that are not relevant for the SDK and are only used in the backend, otherwise it's confusing what the SDK needs to support and what is irrelevant. This is to declutter. So, assuming that openapi-typescript or similar supports this, it will still be maintenance heavy because you need to keep the allowlist in sync.

Honestly, if the API spec changes and you use something, it will break at runtime and should be caught by tests/storybook. If the API is expanded and you try to use it, the typescript compiler will complain about the type not being defined (correctly) and then you expand the type definitions.

I don't think there will much overhead from updating the types tbh.

[robinmolen]

Okay, I prefer knowing (and having types for) entire objects. Just to have a clear overview of what i can expect. But I get wanting to keep it contained to just SDK specific stuff...

I've worked with one of such packages (not 100% sure if it was openapi-typescript, but it sounds very familiar), but there we could specify which object schemas to use when generating the types (which should help filtering to the information that is needed/interesting for the SDK).

And yeah, we will still have to update the SDK when the API spec changes, but this would cut back on the amount of double manual work..

But we can continue like this for now

[sergei-maertens]

Okay, I prefer knowing (and having types for) entire objects.

Even that is tricky - the API spec also documents fields that are returned only to logged in administrators, but are not available to anonymous users getting the form details. We'd need a way to strip those out, because they are not present in the API responses made by the SDK :)