Transcript
In this video, I'm exploring the Vibe-Coding block in Softr, which is a custom code block with AI that allows you to build anything you want. Because it's code, you can customize it via manually editing the code yourself or by chatting with the AI to iterate on the version. This means you can create custom designs and actions to directly interact with your data source.
These sources can be Softr Databases, Airtable, Notion, Postgres, Superbase, Xano, or all the other data sources available to power your Softr applications.
[.blog-callout]
Note from Softr: While Softr seamlessly integrates with external tools like Airtable and Notion, you can also use Softr Databases to manage your data natively. It offers maximum performance and keeps your app architecture simple.
[.blog-callout]
Let's go into it with a practical use case of building a personal trainer view for a client portal. This allows clients to view their sessions and easily edit their movements and the weight tracked on each movement.
[.blog-callout]
Note from Softr: Custom interfaces where users log in to securely access only their specific data are a great example of building client portals with Softr.
[.blog-callout]
In this example app, I'm using Softr Databases for a personal trainer to store their clients. These are the users of the app, and here's a test user. The training sessions for each user are logged here as well.
For example, there are three training sessions here for this user logged into this system. Each session will have movements or exercises that the user will perform as part of the session. Each movement has sets, reps, and weight used that can be tracked by the user or by the trainer, plus any notes.
Now, in the interface of this app, I want to build a view of sessions that looks elegant and doesn't simply use any native block in Softr. I want to use a more custom design, and that's when I can test out the Vibe-Coding block. This is available under AI and then Vibe-Coding block here.
As usual, you set the name, which could be a view of sessions. Then you can see there is a chat where I can ask AI to build the view to start. Here I can optionally select the source where the data displayed in this view comes from.
This is used for dynamic data. If I want to display the sessions for the current user from my database, then I would use a source. Otherwise, I can leave this empty if I'm just building a static block with text and images.
In my case, I'm going to use a source. I will select Softr Databases, or I can use any other source including Notion, Airtable, Coda, Postgre, Superbase, and everything else available in Softr. Then I can set the table, which will be the sessions table in my case.
As in any block in Softr, I can use conditional filters to show only the sessions for the current user. I'm going to set this session filter so the application matches the logged in user's record ID. This dynamically filters the view so that the user only sees their own data and not anyone else's.
Then there is the actions tab where we can set actions to write data to the database, like updating, creating, or deleting records. Next is the content tab, which is where the custom code generated by the AI is displayed and can be manually edited. Finally, there's visibility.
That acts per any Softr block where I can set who can see this specific section. I can also further drill down into user groups that I can set on the users tab, but this is outside the scope of this view.
In the chat, I'm going to start by asking for exactly what I want. Let's say I want to build a calendar view of sessions with a minimal and elegant design. Here, the AI is writing up the code that will then be displayed on the UI.
Okay, the first version is done, and it perfectly respects the app's styling, fonts, colors, and other brand toolkits set up in the theme section. If I go to content, I can see the code and review this first version. Over time as I chat and change things up, multiple versions are created so I can restore them easily.
There are no actions yet and the code can be manually edited. This is very useful because if you don't want to go back and forth with the AI chat over and over again, you can easily tweak it yourself. You could also paste this code into your LLM tool of choice with your past chat history to customize it to your liking.
In this example, let's assume I want to allow the user to open each session in full screen. For this one, I will probably need a details page which I haven't created yet. Let's see what the AI does, and if it asks me to build the page I will optionally build it then.
[.blog-callout]
Note from Softr: If you ever need to quickly generate full pages, complex database schemas, or even entire functional apps, try the AI co-builder. It builds complete functional foundations instantly that you can continue to customize.
[.blog-callout]
I can preview from here, and in the preview, I can click on a session. It opens a modal where I can see the date, time, status, and session ID. I don't want the session ID to show, so that's something to remove from the modal later.
This is pretty good as a start, and I can also scroll through different months of the calendar to see future sessions. Now I want to make a few changes in the chat. The first one is to align days at the top to the left.
Then I want to color code sessions by their status, making them green if done and keeping the default color if not done. I also want to only show the session name, date, and status on the modal. Finally, I will ask to display related session movements inside the modal and make the modal larger.
Looks good, so let's preview it. The names are left aligned just like I asked, and the sessions are properly color-coded by status. These two are completed so they are green, while this one is not done yet and remains the default color.
If I open a session, I can see the date, time, and the status. The modal looks a bit wider, although not exactly as I expected, which is fine since I didn't specify the exact dimensions. The session details are still not displayed in the modal yet, so that needs to be fixed.
I can also check the different screen sizes to see how everything looks. The tablet version looks pretty good but the text is somewhat truncated. We could fix this by setting multiple lines on the session name, and address similar formatting adjustments for the mobile view.
Alternatively, we might create an entirely different view that's more suitable for smaller mobile screens. For example, a list or table view for sessions might work better than a calendar that gets squeezed down. I want to make a few additional changes, so I'll send them in the chat.
One of the changes involves allowing users to take an action, which should use the actions tab to update the record. When I preview this, I don't see the movements. I can see one session is done, so I can't change the status.
But if I open a session that is not done yet, I can mark it as done to change its status to completed. I also want to be able to reverse this action, so there needs to be a way to switch it back. I want the session movements to be better organized and the modal to be bigger.
When I switch to the actions tab of the Vibe-Coding block, I can see there is an edit action. The field used is the status, and I can set visibility to only show for logged-in users. I can also set specific conditions, which were handily set by the AI so the button is only visible when the session is incomplete.
I will preview the latest changes and see if they are correct. If I open a completed session, I can see the option to mark it as not done, which is exactly what I wanted. The modal is also slightly larger.
I can now see the session movements in a table format, just as I requested. I can edit the data in here, although it currently behaves strangely. For example, I tried to edit the sets, and that is not working as expected.
This needs to be fixed, so I will go back and generate a new version of the block. It looks like the updates persist now, which is exactly what was needed. We can edit text fields like sets, reps, and weight used, but restrict editing on the movement name itself.
If we look at the data, the manual adjustments actually save to the database. I changed the weight to 55 for the front squat, and it persisted perfectly. One thing I had to do to fix this inline editing was change the source of the Vibe-Coding block.
I switched it from the sessions table to the session movements table. This ensures we can include the editing of those fields appropriately in the actions tab. It is an incredibly functional block already, though there are certainly still improvements that can be made.
There are also a few things that
