With the AISDK, we can generate bespoke user interfaces. This is not about generating random HTML and CSS as if you were using a site builder with an LLM. Instead, it's about more deterministic output. A great example of this is already supported in the chat template.
I can ask the LLM to tell me the weather in my current location. The output is this beautifully styled weather card. This isn't a weather card that will look different every time the LLM responds with information about the weather. It's a card that we have created a view component for in our project.
And we control the style and the layout. The LLM simply plugs in the props. I can even ask the LLM to chart this weather data on a line graph. After some thinking, it is able to do exactly that.
So how does this actually work? Well, over in the AISDK docs, they break it down for us very simply. This is the process. Number one, we provide the model with a prompt or conversation history along with a set of tools.
post. where we're streaming the text, we're providing two different tools, a weather tool and a chart tool. So step number one, check. Step number two, based on the context, the model may decide to call a tool.
Obviously, this weather tool is very relevant to the context with this message. And so indeed, if I look at the dev tools for the AISDK, When I mention it tell me the weather in Tuscaloosa, Alabama It does go and call that weather tool see the little wrench icon right here What the assistant passes in to the weather tool is a location argument of Tuscaloosa, Alabama The tool then goes off and calls some API to get this data back for that location Leading to this textual output from the LLM. This output is shown clearly in our chatbot after the weather card is displayed, but it's the result of this tool call that actually gets passed in to a component to create the card. View, the tool weather component is used to handle message parts of the type tool weather.
All of your generative UI tool components should take an invocation prop. Let's open up tool-weather and take a quick look at its definition. Notice the invocation prop is typed with an auto-imported type. Where does this come from?
ts. So tools, under a shared-utils directory, is a great place to store all the tools in your AI applications. Notice we've got one file for each tool for easy organization. Here is that weather UI invocation tool built with a UI tool invocation helper utility from the AISDK.
You simply pass UI tool invocation the type of the actual definition of your tool. So notice right down here, this is where we define the tool. with the tool function like you learned about earlier. The execute function is where we go and make an actual API call to some weather service.
In this case, it's just throwing together some random numbers, but you get the idea. So this weather UI tool invocation type is used to type the invocation prop for our component. Inside of the component, the majority of things is just about adding the output. to the page.
This output of course all depends on what your tool does, but it's all determined by whatever is returned from your tool's execute function. The other thing we need to be concerned with inside of these tool components is the state of the streaming process. This gives us control over what things look like once the output is fully available. e.
the tool has been called with its arguments, but it hasn't yet returned a response. This is great for displaying some kind of loading indicator. Finally, this state even lets us see if the input is currently actively streaming.