State and bindings panel

[joebudi]

With the new bindings and state panels, you can quickly understand what Data is available at any given moment when designing your app.

Problem

Binding data to components is a critical part of building apps within Budibase. Every user has to undertake this experience, but when designing apps with Budibase, it’s challenging to understand ALL the available data at any given moment.

With today's experience, we expect the user to click the lightning bolt (is this obvious?) and use the binding drawer. Within the binding drawer, the user has to decide between Text and JS, which is a hard decision considering they are new to the platform. Then, they must navigate the long list of Bindings within a small section of the drawer. It’s challenging to navigate ALL the available data. 

When building apps with Budibase, it's common for users to use State. We encourage the usage of State with the side panel experience. A screen can contain multiple usages of State, but it's difficult to identify where state has been used. Testing State is difficult, the value is always null in the design preview. As a user, I have to preview the app and trigger the state event to test it.

User feedback

User 1:

"An easier way to view the structures of the data you're attempting to bind onto - today we list the various bindings that a user could use - but we can't list every individual property/detail that can be bound to. For example we will offer a binding to a relationship column in formulas/screens, but we don't list the properties that are within the related rows. Discussions like this: https://github.com/Budibase/budibase/discussions/15241"

User 2:

"It would be great for development to have an overview of where state variables are used and what breaks if you'd change something." I pulled this comment from a github issue.

User 3:

"Find usages"... e.g. Where is the "Customers" view used, down to the component? Where is this input used on the screen, i.e. by other components? Where is State value used?

User 4:

"An easier way to see the bindings/styles used on a page - Budibase is a very component-driven application, we all our JS/styles happen at the component level; I think this is generally very confusing for people because traditional web development is very global. If we offered a more global view to bindings/styles for a page I think this would go along way to helping those with some understanding of traditional web development get how BB handles JS/CSS on pages."

User 5:

"there's a lot of trial and error when building, or adjusting settings blindly. some concepts (like state) are hidden away in menus a few layers deep. it would be very handy to have visibility of and control over stuff like form field values or state values somewhere central in the design view. this would greatly help when working with features like conditional rendering which is quite hard to test at the minute"

Community poll:

We ran a poll to determine what features the community would like to see us build in 2025.
View state variables/queries came out on top.

Appetite

We have 6 weeks' appetite for this project.

Solution

There are multiple parts to this solution.

1. Bindings interface

Show all available data, including state, a user can bind to within a side panel and allow the user to drill into that dat. Each available binding, when clicked, should get added to your clipboard so the user can quickly bind data to their bindable text input in the settings panel.

Within this panel show a list of components connected to that specific state. The components listed should be linked and, when clicked, should highlight the component and setting within the design preview/settings.

2. State interface

We originally planned to include the state interface within the global bindings interface, but @aptkingston rightfully suggested separating them due to their differing experiences. With the State interface, we must provide users with a central way to view/understand what State is used on their screen. Users can also see the components linked to a state; when a linked component is clicked, it is highlighted within the design preview.

3. Live eval on "Value" inputs

As the bindings are added, Budibase will eval the binding and provide a preview of the output.
The textbox should expand (vertically) to accommodate up to four lines of text. If more text is required/added, a scrollbar should appear, and the user should be able to scroll to view all the text.

4. Queries: linked screens/automations

Within the query interface in the data section, reference the screens and automations linked to the Query - in the same fashion as Views and Tables.

Rabbit holes

From a design perspective, we need to understand the hierarchy. Screen navigation is the top level in design, so the navigation we’ve proposed requires additional thinking as it sits alongside nav items that are reliant on screen choice.

No Gos

• It’s also challenging to understand the components linked to specific state/queries/data. 
• From the data interface, we’ve made this easier for tables/views, but not for queries. 
• It’s only possible to add handlebars to the textbox. JS must be added via the bindings/JS drawer.
• Removing spaces in bindings
• Typeahead - no need to add typeahead to the bindable text input within the settings panels, allowing users to type something like “current”.

---

Added to scope

Users don't have a way to test state within the design preview. We should provide an input that allows them to add a test value to their state so they can test it within the design preview.

[linear]

BUDI-8995 State and bindings panel

[mjashanks]

Regarding the state panel:

An extremely useful addition here would be to allow setting of URL parameters in the design preview

e.g. /customer/:id > would like to be able to set the :id parameter

[joebudi]

Bindings panel PR: #15403