-
Notifications
You must be signed in to change notification settings - Fork 9
Description
Came up talking to @seefeldb. Currently, we generate javascript and transform it at runtime using babel within our iframe. We also do a bunch of gymnastics around loading libraries and ESM modules.
If we generated typescript instead we could compile that using the same path in localBuild.ts we've used in the past. This lets us write standard import statements, do typechecking, transform JSX and emit one bundled output to run in the frame.
We can provide our standard API's via imports (useDoc, llm, readWebpage) instead of a large HTML string. This also means we can provide the latest versions of these functions rather than 'baking them in' to the charm.
To start, we can do the compile on every load. Later, we can cache it.
We can get a few wins in one go with this:
- typesafe recipes
- single compilation pass (with cacheable output)
- no more 'what version of useDoc is this using?' confusion
- faster development feedback loop
- Allow user to switch between "prompt templates" in composer #736
- templates could be simple, just a 'set of available imports' in this version
- "Fix it" should not be able to rewrite the entire page template #725
- prompting within a charm: a lot of low hanging fruit to improve #726
In general, this is a saner approach and requires less 'explaining' in the system prompt as a result. I expect the generated code would look very boring:
import { useDoc, llm } from '@commontools/lib'
import * as React from 'react'
import * as ReactDOM from 'react-dom'
const Counter = () => {
const [count, setCount] = useState(0);
return <div>{count} <button type="button" onClick={() => setCount(c => c + 1)}>Increment</button></div>
}
ReactDOM.render('#app', <Counter />);
That alone should improve our LLM results, and simplify reasoning about this whole stack.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status