Going from Budibase "Quickstart" to a basic understanding of application structure was a bigger step than I had expected, but I think I'm there now. Here are some notable lessons from my first (and second) passes through Budibase documentation with the caveatI wouldn't know for sure I got this right until I get some hands-on app-building experience.

Blocks Are Not Components

When reading Budibase documentation on user interface elements, I came across terms like "Form", "Form component", and "Form block". I thought they all referred to the same thing, that words "block" and "component" were synonyms. I was wrong, which caused a lot of confusion. A component in Budibase parlance is a single interface unit (example: textbox) and a block is a predefined composition built from multiple components to address common scenarios. (example: form block contains many textboxes.)

The ability to "Eject block" was mentioned in "Quickstart" but I didn't understand what it meant at a time. I had understood it as a way to break up into smaller pieces so I can access its internals for customization, which should be great for learning how it was built under the hood. But most of the time when I wanted to look inside something I couldn't find that "Eject" button. Eventually I figured out I had been trying to eject components and that's why I got nowhere.

Data Provider, Repeater, and Binding

I've learned that things are a little more complex than 'database stores data, components display data, binding connect them together.' A few additional pieces are required. First is the fact we don't want everything in the database all at once. For tasks like filtering or pagination, there are "data provider" components that fetch a desired subset from the database. The subset is still a collection of data, so a "repeater" component is deployed as an enumerator. Child components of a repeater will receive that data one row at a time, and that's when UI components can use a binding to pick up the exact information they want. A hypothetical example:

  • Database: "Employees" table

  • Data provider: "Name" of first 50 employees sorted by name.

  • Repeater: for each of those employees...

  • Paragraph: display text of "name" binding.

When we use a Table block (like the auto-generated screens in the tutorial) these steps are handled automatically. But if we want to built tailored UI, implementing these details become our job.

App State

Sometimes an app will need to convey data between parts outside of the standard data flow hierarchy. (Provider, binding, etc.) I was curious how it was done and hit "eject" on an existing block to see its implementation details. The answer is app state, an application-wide key/value store. Or in other words: global variables!

With these lessons in mind, I am ready to start building my Budibase app to work with my existing data on personal transactions. And wow, it's a mess.