Is the value of the “Name” from a Tab Container accessible to the Screen? In particular, to test in the visibility of a component.
I don’t see it (so probably not) but I wonder why it is part of the Edit tab if it isn’t usable.
Thanks as always
Is the value of the “Name” from a Tab Container accessible to the Screen? In particular, to test in the visibility of a component.
I don’t see it (so probably not) but I wonder why it is part of the Edit tab if it isn’t usable.
Thanks as always
I don’t think so.
I think if you care about the visibility of components outside the container, you should use Tabs, not Tab Containers.
I’m not sure I understand this right, but you still have this to Edit how the Tab Containers would look like right?
Yup, scroll down to the bottom of the pick list of components and find the Tab component. This has extra fields that you can leverage elsewhere in your app. I almost never use the Tab Containers component tbh.
Tab containers is good in simple use cases where you don’t want to go through the trouble of creating the user specific column necessary for the tabs component.
I highlight the differences here:
Do Tab containers use updates when the screen containing them are a non-Glide table? The state information has to be stored somewhere or is it a locally stored on the device?
Just trying to figure out the difference not just technically but also fiscally between Tab containers and Tab components.
With the recent push by Glide for excel tables (and other non-Glide tables) using these types of tables as the screen source means Tab components very likely will drive a majority of updates for a an app (mileage will vary) especially if the User table is also a non-Glide table (the other place to store near-universally accessible local data).
I believe Tab containers would drive no updates and Tab components would drive lots of updates (non-Glide tables) which may mean trade-offs in design given flexibility differences between the Tab solutions.
Tab Containers, no, since they don’t specify a source to store the “state”.
Tabs, yes, if you store them as a non-user-specific column in an external source.
Can you show where Glide has pushed this? I don’t think they should ever prioritize anything other than their own tables.
Look at their Instagram account ![]()
Spreadsheets are back!!
I doubt that’s the intention at all.
I think Glide promoting turning existing IP (spreadsheets) into efficient business tools is a solid message.
Remember that Glide is a “for profit” company and they have a marketing department whose sole purpose is to drive profit. Marketing’s job is to pull in more customers, and if that means catering to those with existing data sitting in spreadsheets, they aren’t going to leave that money on the table.
There will always be additional costs to Glide to integrate with external data sources, which they pass down in the form of update quotas. At the end of the day, keeping data in-house is always going to be simpler and cheaper for them, but they don’t want to exclude potential profit by excluding potential customers with external data who may not want to move to an internal data source. External spreadsheets just happens to be their marketing strategy of the moment, and a lot of excel users are typically businesses with the big bucks to buy enterprise plans. They are promoting spreadsheets right now, because…why not…
This does not mean that Glide is shifting focus from there internal database to external ones. It just means they are reiterating that they have the capability to connect to external data sources if need be. It’s purely to bring in new customers. That does not change the cost burden to them to provide the ability to connect to those external sources, but if they net in the black for a customer using Excel or Google, then it’s always a win and keeps them in business for the rest of us.
Internal data sources will always be cheaper and simpler to implement and maintain. It’s fairly easy to utilize a Glide table for tab control even if your data resides in external data sources. All you need is a single row helper table with user specific columns to store the chosen tab, and in your other tables create a Single Value → Whole Row column to the helper table. Then it’s just a simple matter of storing the chosen tab in the helper table through the single value column.