Is your enhancement related to a problem? Please describe.
At present the dynamic page builder requires the need to cast with as operator in TS so that types align, however this presents problems in terms of e2e type safety as it bypasses the compilers checks and could lead to runtime mismatches.
Currently the page builder type is pulled from a query, as no other way exists at present for Sanity typegen to generate the result type.
Even though Sanity as a data source is trusted, it still feels like a type safety gap not to have some form of validation, predicates or data normalisation process for page builder data to section prop shapes.
The possible solution could be to wrap all section components in a transformer/normalization data HOC that accepts the page builder result and transforms the data to the specific UI component prop shape. This provides a greater level of separation from back-end to pure ui component.
Finding a scalable way to support this without requiring very complex Zod/Valibot schemas will be crucial.
Recommend a POC is handled first to see what can be achieved here, the goal should be improved E2E type safety, where a page builder section schema change does cause a type error due to the generated types being mismatched, where the current casting approach could prevent such an error from surfacing.
Designs
No response
Describe alternatives you've considered
No response
Code of Conduct
Is your enhancement related to a problem? Please describe.
At present the dynamic page builder requires the need to cast with
asoperator in TS so that types align, however this presents problems in terms of e2e type safety as it bypasses the compilers checks and could lead to runtime mismatches.Currently the page builder type is pulled from a query, as no other way exists at present for Sanity typegen to generate the result type.
Even though Sanity as a data source is trusted, it still feels like a type safety gap not to have some form of validation, predicates or data normalisation process for page builder data to section prop shapes.
The possible solution could be to wrap all section components in a transformer/normalization data HOC that accepts the page builder result and transforms the data to the specific UI component prop shape. This provides a greater level of separation from back-end to pure ui component.
Finding a scalable way to support this without requiring very complex Zod/Valibot schemas will be crucial.
Recommend a POC is handled first to see what can be achieved here, the goal should be improved E2E type safety, where a page builder section schema change does cause a type error due to the generated types being mismatched, where the current casting approach could prevent such an error from surfacing.
Designs
No response
Describe alternatives you've considered
No response
Code of Conduct