[VIDEO] How You Should Be Using Tables

build.marshall · 2024-08-31T10:27:23.454Z

Here’s an approach that could help you seriously level up how you use Tables in all of your apps.

I hope everyone enjoys this quick look at how I use data in tables within my Bubble apps to get more out of my products.

Also please excuse the shameless plug of our Bubble Black Belt Skool community - which has just gone live!

Nick

adamhholmes · 2024-08-31T18:19:13.312Z

What’s the logic in using a custom state for the Group’s datasource? (I can’t see any benefit to doing that, only additional complexity?)

build.marshall · 2024-09-01T00:01:20.718Z

I definitely should’ve gone through my thinking behind that in the video - thanks for the heads up.

If I’ve got an item (as in the example above) that has a number of different connected data types, e.g. a project with attached notes, documents, meetings, etc, then using the custom state as the data type becomes a channel to accessing everything via a Parent group instead of having to reference the custom state constantly in the ‘ViewGroup’.

That means that as I build out points of access to the connected data types for that item, all I need to do is add in ‘parent groups [data type]’ for each new group instead of referencing the custom state every time.

In essence, once I set the data type of the View group as the custom state, I then don’t have to directly reference the custom state again at all in any of the groups that I create within the ViewGroup - just the parent group.

So while building out the access points in the view group, instead of having to do:

‘[Group ViewProjects] [custom state]’

it’s just '[Parent groups Project].

Does that make sense?

I think for my own clarity during a build I like to anchor to a group rather than a custom state, which is achieved in this case by setting the ViewGroups data source as the custom state.

adamhholmes · 2024-09-01T00:08:38.665Z

But why use a custom state as the ViewGroup datasource, rather than just setting the ViewGroup datasource to the Project directly? It seems like a redundant step (not that it doesn’t work).

build.marshall · 2024-09-01T00:29:27.948Z

Ahh got you, sorry I misinterpreted your question.

If I set the viewgroup datasource to the project directly then I’d also need to put additional steps in the workflow to show and hide the viewgroup and reset the data when a user finishes with it wouldn’t I?

With the custom state approach all I need to do is set a workflow to clear the custom state and it essentially resets the inputs and hides the viewgroup in one go, because I’ve got the conditional expression that viewgroup is only visible when its custom state is not empty.

So instead of doing a custom state and setting the datasource, the custom state is my source of truth for both.

animisha45 · 2024-09-01T02:53:29.036Z

build.marshall:

I’d also need to put additional steps in the workflow to show and hide the viewgroup

I believe in this case, You could add the conditional ‘this groups data is not empty’ and reset when user goes back. so no extra steps.

build.marshall:

the custom state is my source of truth for both.

Personally, I like url parameters as well.

build.marshall · 2024-09-01T03:52:08.589Z

It’s probably a reflection of how sad my life is but I’m pretty keen to map out all possible ways to do this and compare them - I think some of it probably comes down to the other uses I have for custom states when using tables and RGs.

Setting the data for the group is probably what you’d call the expected approach, but I started leaning into / getting experimental with custom states a while back and just sort of ran with it.

I think that for me it feels consistent to have the custom state as the switch for showing/hiding the group, filtering the table by the item unique ID, and then setting the data as well. Again, probably just preference.

adamhholmes · 2024-09-01T09:31:38.645Z

build.marshall:

If I set the viewgroup datasource to them project directly then I’d also need to put additional steps in the workflow to show and hide the viewgroup and reset the data when a user finishes with it wouldn’t I?

No not at all, just use the group data instead of the custom state (or use the custom state instead of the group data) - but there’s no need to use both.

I mean, there’s nothing wrong with it, if it works it works, but I always try to avoid redundancy and doing things twice, or adding additional complexity where it’s not needed.

BTW I really like what you’re doing with the bubble black belt courses… it looks like a great way for people to learn Bubble.

build.marshall · 2024-09-01T23:04:46.853Z

Definitely agree with the double handling stuff and trying to avoid over complicating anything when developing. Thanks for the feedback and comments with this - got heaps more content to come.

Appreciate the feedback re Bubble Black Belt as well! If you’ve got anything you think would be good content in the community would love to hear it!

All about giving people options and flexibility with their learning.