Type Safety and Drift Between Functions Repo and React App — Is This the Intended Pattern?
I’m using a Functions repo as the primary layer for queries and actions against my ontology — both as a resource for others (workshops, quiver, etc.) and as the backbone of my own React application via an OSDK-based SDK.
The problem: because Workshop has historically had inconsistent support for structured types, I’ve defaulted to using strings instead of properly typed objects throughout my functions. This means by the time I’m in my React app, I’ve already lost type inference. I end up redefining types in both repos, and even though I control both, the drift risk is real.
I considered publishing a shared NPM package to centralize the type definitions, but that feels like the wrong abstraction inside Palantir — I’d essentially be papering over a gap in the platform rather than using it correctly.
Questions
- Is the string-over-struct approach a known workaround, or am I genuinely misusing the platform? The Workshop docs suggest structured types are supported, but my experience hasn’t matched that.
- Is there a canonical pattern for sharing types between a Functions repo and a React app without redefining them manually?
- As the OSDK React SDK matures, is this expected to get better — e.g., first-class type inference from ontology types into the frontend?
Happy to be told I’m holding this wrong. Mostly want to know if there’s a better path before I invest further in the current setup.