Now that we have the basic React flow example ready, let's do the necessary changes so that the nodes no longer look like this but instead are more similar to this. Now in order to achieve this we are obviously going to have to develop some custom node components but it will also be a good idea for us to develop something called a node registry. You can think of that as some kind of manifest which every single node will have to satisfy. So every node will need to have a title, every node will need to have an icon, every node will need to have its accent color like green, blue, red, etc. Every node will also have a type.
Is it a trigger node like start or is it an action node like open URL, extract, etc. And that's also how we're going to separate them here in this right sidebar. And the reason we are developing this in that kind of registry, manifest is so that we only have to develop one or two nodes ourselves in the beginning and then we can easily point our agent and tell it using this node registry or the manifest, develop the agent node or develop the extract node, develop send email node. That's how you use agentic coding to your advantage without losing control of the code you want to generate. So what I've prepared for you in the GitHub repository is the templates folder.
In here you will find two files. The first one is the node registry which I was just talking about. This node registry will define the step node kind, which can either be trigger or action, the node field, node definition, and the actual node registry with all the required types for each node, which satisfy the node definition. We're also gonna export some additional node types. And in my opinion, it doesn't really make sense to try and prompt to generate this because we really cannot leave it to chance for this to be non-deterministic.
It will be much easier for you to follow along if you have this manifest exactly the way it's written here. And then later we can use the Gentic prompting to enhance this manifest, to add new properties to the node registry and to use it to create new nodes. That's why I feel it makes more sense to simply inject this into our code base because it's not really a large file, but it is very specific with its types. And that's what makes it a manifest, a definition, something we have to satisfy and the second file I've added here is a custom step node component. The reason I added this as opposed to try and generating this is because of the class names.
Chances are you and I are not gonna get the exact same class names and it will just be annoying to follow the tutorial where you have to fight with your agent in trying to generate the exact same style of the component. So make sure that you are in the main branch or simply find chapter 10 once it's available and use the templates folder. The reason I'm telling you to use the templates folder and not the actual features, workflows where we are going to put these files is because this template is just the initial state of these files. We are going to work and add on top of them. So I want you to have the exact version you need to have right now.
That's why maybe preferably use chapter 10 branch and then get them. But using them from the main branch should work just fine. So inside of features workflows create a new folder called nodes and inside put the node registry component and just ensure that you have everything that I have here. So step node kind, node field, node definition, the actual node registry, which has two nodes inside, one start trigger node, and then one open URL action node with some fields, which just have a youtube.com placeholder. This exact node registry needs to satisfy the record string node definition.
We need to export node type which is a key of type of node registry from here so we know which nodes are available so this will result into start and open URL and as we add more nodes, this node type will expand. And you need to have step node data and step node type. Now obviously we are going to improve on this but for Now this is a perfect start. And then go inside of Features, Workflows, Components, and in here add the Custom Step Node Component. And when you copy it from here, just make sure that you modify this import right here.
So just change this to be workflows nodes like this. The reason I put this import in the templates folder is because if the import is invalid it breaks the build. So just make sure that you have a valid import in the step node, which you put inside of features, workflows, components. So you should now have node registry inside of your features, workflows, Nodes folder, Node Registry, and you should have StepNode component inside of Features Workflows Components StepNode. And that StepNode should have the Features Workflows Nodes Node registry import where it gets the node registry and it gets the type Stepnode.
And you can see how these two components are connected using their types, I mean sharing their types and also extracting from the node registry based on the type that this Stepnode component data has. To not leave you in the dark, I will just quickly go over this Step Note component. So majority of this styling here as you can see, when selected, add ring, rounded radius, border too, it's just to make it look as in this picture right here. Okay. That's it.
A bunch of these styles are just for that. Now about this hasTarget thing and the handle component, well that's basically to determine whether this is a start node which should only have one handle or if it's an action node which should have like an input and an output handle. So you can see that we check has target, meaning a trigger starts to flow and takes no input, so it has no target handle. So we make sure that we only render this first handle if we do have a target, right? And every other component has the other handle on the other side.
And everything else you see here is just making it look like it's supposed to look like. Nothing really educational in me showing you every single Tailwind class name here. That's why I feel like it's more useful for us to just copy this template, but understand what we are copying. So now that we have these two files, StepNode and NodeRegistry, it's time to wire them into the actual canvas component so that they appear here instead of these default nodes. So go ahead and prepare your canvas component.
One thing I forgot to tell you which could be very useful, remember when we set up React Flow, We weren't able to find skills or MCP service for it, but we were able to find a React flow LLMs TXT. The problem is we have to remember to add that context every time to Cloud Code. So what we could do instead is we could update our agents.md or cloudcode.md, whichever one you use. Since we did a symbolic link, we can just update any of those. So go ahead and prompt your cloud code something like this.
So update agents MD so that every time we have to use React Flow API components or just usage in general, we don't rely on training data but instead we search HTTPS React Flow.dev LLMs.text. And the output should be something like this. It will probably have some differences but ReactFlow, don't trust training data. This project uses ReactFlow, XyFlow React for the canvas. Its APIs, components, hooks and props change across versions and may differ from your training data.
Before writing or changing any React flow code, fetch and consult the official LLM docs index at LLM's text and follow the linked pages relevant to what you're building. Do not rely on memory for component names, props, hook signatures or usage patterns. Great I love this change. So yours should be something similar to this. It doesn't have to be word for word.
So remember, every time you don't have skills available or MCPs and the only thing you have to work with is llms.txt, it's a pretty good idea to add that to Agents MD so every time you reference React flow it will know, hey I have to look at the documentation first and not rely on my training data because you can't really know what data this was trained on. Now to render the new StepNode component inside of our Academus we have to do the following. I honestly think it's worth doing this by hand rather than writing a prompt because writing a prompt would actually take longer. So first things first, make sure that you import the StepNode component from Components StepNode and the type StepNodeType from Nodes, NodeRegistry. Then let's go ahead and define the custom node types object here.
So node types and go ahead and import node types from xyflow react. So make sure you have that import here and simply add step, step node. Now let's go ahead and modify our existing initial nodes. So right now we just have two dummy nodes here. So we can replace this array with step node type array and just a single object inside ID of start type step position x, y, 0.
And then data, Now be careful here. So type needs to be start, kind needs to be trigger, title needs to be start and values need to be an empty object. Then let's go ahead and let's clear the initial edges and let's go ahead and register the node types in the React flow here. And once you do that, if you go ahead and refresh your canvas, you should see your brand new node here. Since this is a trigger node, you will notice that you only have a handle on one side.
It doesn't have a handle here because it's supposed to start the data flow and not accept any data flow. In your canvas component, you're now going to have one unused import so you can remove type node from XY flow react. This is a pretty good place for a checkpoint. So let's go ahead and commit these changes. This way you have a checkpoint for this custom nodes and node registry and all the wiring that went into the canvas.
And Now you can play around and you can tell your agent to do the following. Modify the canvas component so that initial nodes also render a open URL node, which we define in the node registry. And just like that, you can see how easy it is for us to utilize Gentic coding to do the work which we would usually have to do manually, but we can now do very reliably because we implemented that manifest, the registry, right? So we can trust the code that's been generated because we have such a good base of existing code. The actual code change will look something like this.
So no need for any new imports. Instead of the initial nodes in your canvas components beneath the start node, you should now have ID, open URL, type step, some slight change in the position and then the data here. Feel free to play around a bit and maybe tell your agent to create a few more nodes and maybe connect them but after you are done I would recommend actually just reverting the changes and making sure that the only node you have on your canvas is the start node simply because this will be the actual look of every new workflow which is created, right? So every new workflow that gets created is going to get initialized with a start node And then we're going to develop a toolbar here, which will allow us to add new nodes inside.