feat: AI block UI #980
feat: AI block UI #980
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
There was a problem hiding this comment.
In general looks good, I only looked at the overall architecture for now (not line-by-line). So far I have a few main comments:
Extracting package
Just realizing this now, I think we should try to ship this as a separate package. Two reasons for this: (a) it's likely this may be licensed differently (i.e.: GPL / Pro only) and (b) it would be a good "proof of the pudding" to see whether we can externalize larger plugins / extensions in a way that still makes sense
Duplicated toolbar code?
I think we're starting to see a lot of similar code with the AI Toolbar and plugin that we already have for FilePanel and LinkToolbar, right? If so, it might be a sign that we need to generalize this code and reduce the duplicate code
AI specific
- We need a way to pass in the
mockAIModelCallfunction - The AI Model call might need access to the rest of the document / blocks above / below the block
- I think the current mockup is some good first steps but the Notion AI Block is definitely more polished. Specifically, I like their "Generated by AI x minutes ago" context and don't really like our "show prompt" button.
wdyt?
packages/xl-ai/src/AIExtension.ts
Outdated
| /** | ||
| * zustand design considerations | ||
| * | ||
| * - setters are not added in this store, but as class methods so we can have control over what to expose as API | ||
| * - con: if we'd expose the store externally, consumers could still call store.setState :/ (for this store it's not desired, for `options` below, it is) | ||
| * | ||
| */ | ||
| public readonly store = createStore<AIPluginState>()((set) => ({ | ||
| aiMenuBlockID: undefined, | ||
| aiMenuResponseStatus: "initial", | ||
| })); |
There was a problem hiding this comment.
Agree that setters being in the store would be weird, assuming that you have access to the class methods. If you didn't have access to the class methods, it would basically force all logic to be in zustand, which I think is the wrong way about things.
Being able to update state you don't own is pretty problematic 🙁 (if someone called store.setState), but I don't think we need to solve it or disable it.
There was a problem hiding this comment.
Being able to update state you don't own is pretty problematic 🙁 (if someone called store.setState), but I don't think we need to solve it or disable it.
agree - as long as everywhere else we follow the pattern that we expose separate setters, I think we should be good
packages/xl-ai/src/AIExtension.ts
Outdated
| type AIPluginState = { | ||
| aiMenuBlockID: string | undefined; | ||
| aiMenuResponseStatus: "initial" | "generating" | "error" | "done"; | ||
| }; |
There was a problem hiding this comment.
What if this was a union, would setState be able to enforce this properly?
Like, what if it was:
type AIPluginState = {
aiMenuBlockID: undefined;
aiMenuResponseStatus: 'initial'
} | {
aiMenuBlockID: string;
aiMenuResponseStatus: "generating" | "error" | "done";
};There was a problem hiding this comment.
good suggestion, see this commit: 5a529cb
This PR adds all the UX/UI for AI integration in BlockNote according to the Notion doc. The UI is not yet plugged into an API for querying AI models, so it uses a mock function which accepts a string prompt and returns a string AI response.
There are a few differences in the implementation vs the spec listed in the doc:
Updating...string but can easily be changed.TODOs:
Updating...on click.mockAIReplaceSelectionormockAIInsertAfterSelectioninAIInlineToolbarwhile React strict mode is enabled. Everything works fine for the user though.