## 💡 Extracting and deploying Typescript Types on-chain ### 🤔 Context When I first started building on BOS, I explored this idea of a BOS Type System -- you can read [this post from when I first implemented a POC](https://youtu.be/DukrdJtZtSU) and then the [original idea posted on DevHub](https://near.social/devhub.near/widget/app?page=post&id=432) from April, 2023. Essentially, the idea is that widgets have props -> props can follow Types -> If props follow a type, then we can swap out widgets of the same type really easily. Now you can build Templates and Plugins to display or interact with this predictable data, as well as aggregate data across multiple external sources with adapters (@hyperfiles.near), as long as the data follows the same type. [Here](https://youtu.be/DukrdJtZtSU) is a full workshop exploring this concept.  There's plenty more to explore... and that's why we've been building with @archetype-org.near to create a global type registry for this dream of the "unified front-end". ### ❓ Problem I used to get really hung up on the question "What is the best way to define types?" I had created this [type creator](https://near.social/#/efiz.near/widget/every.type.create) with some really basic descriptors, and then had long brainstorming sessions with @sking.near to determine the best JSON structure (he used Types for validation in the Astra++ Create DAO flow). Anyway, enough of the nostalgia; this is all before I knew about [JSON Schema](https://json-schema.org/) and runtime schema validators like [Zod](https://github.com/colinhacks/zod). ### 🚀 Solution [bos-workspace](https://github.com/nearbuilders/bos-workspace) supports writing widgets in Typescript -- it utilizes [sucrase](https://sucrase.io/) to transpile TSX syntax to JSX as done in @frol.near's [bos-component-ts-starter](https://github.com/frol/bos-component-ts-starter). This transformation happens [here, in bos-workspace/lib/parse.js](https://github.com/NEARBuilders/bos-workspace/blob/caa15365979468e3ea66f858f32f0597878a6cef/lib/parse.js#L68). If you look at this code, you'll notice that the transformation simply strips away the type definitions and does some simple replacements-- that means, in the current state, writing widgets in Typescript is only helpful for IntelliSense in VSCode, and not much else. When other's checkout your code via WidgetSrc, [for example](https://near.social/mob.near/widget/WidgetSource?src=frol.near/widget/bos-component-ts-starter.pages.page-a), you don't see the original Typescript that wrote it, so anyone that forks doesn't get the same benefits unless they access the git repository. You can't even find widgets of like type. We should extract these types on build, possibly convert them into JSON schema using something like [typescript-json-schema](https://github.com/YousefED/typescript-json-schema), and then we could deploy to {accountId}/type/{typeName}. We could store this type in the metadata of any widgets that match this schema, in order to make swapping templates or building widgets easier. To add more utility, we could integrate [Zod](https://github.com/colinhacks/zod) into the VM (or create an SDK @mattb.near) and offer a helper for converting [JSON schema to Zod](https://github.com/StefanTerdell/json-schema-to-zod). And finally, if we want it, we could do [json-schema back to typescript](https://github.com/bcherny/json-schema-to-typescript). #build #idea