Not really, although Lookup probably isn’t the correct word when referring to components. But you can use components to display data from tables other than the current one. List components, for example.
The closest we have to this are Deep Links
Yes, but generally I find that adequate. I don’t disagree though that it would be useful to have tables that could be marked as globally accessible. A good use case for this would be a place to store “global variables” or app level settings, both of which usually wind up in the User Profiles table.
Yes, more or less.
I’m not sure why you would want/need to, but yes you can certainly do this.
I don’t really see this as a concern.
I do personally almost always use a Google Sheet for my user profiles, but for other reasons:
- I think it’s good practice to always have a Google Spreadsheet as the data source for your Glide app, due to some of the current limitations of Glide tables. Most notably the difficulty in importing/exporting in bulk, and integrating with external sources (API’s, etc). So when I start a new app, the first thing I usually do is create a Google Spreadsheet with a single sheet, which becomes my User Profiles table.
- Often some of the data in my User Profiles is sourced and/or shared with other applications, so it’s easier to do that if it’s based on a Google Sheet.
- I use a lot of Apps Script in my projects, so I always need a Google Spreadsheet.
Nope, not that I’ve noticed. Glide computed columns are incredibly powerful, and because everything happens locally on the user device there is rarely any noticeable degradation in user experience as the number and/or complexity of computed columns increases. I have one app that has roughly 1500 computed columns, and it works fine.