LinkedIn
Twitter
Iโve noticed that many of the official sample apps from AppSheet are NOT built using good practices.
Take the โWorkstation Trackerโ sample app, inside Iโve found the following โbad practicesโ on one table alone
- The RED outlined VCs shouldnโt be VCs
- The GREEN outline VC should use a (slice)
- The โRelated Distance Checkerโ columns donโt need to be REFโed
The RED outlined VCs shouldnโt be VCs
- They should be physical columns
This is because they donโt contain data that changes dynamically; the data they contain only change based on changes to the record.
- When youโve got data points like that, you donโt store that computed value inside a VC - you store it in a physical column with an app formula.
The GREEN outline VC should use a (slice)
The Occupied column uses a brute-force SELECT() (ported into a FILTER formula) to pull any ongoing workstation checkouts.
- This should instead be a REF_ROWS() to a slice of the ongoing workstation checkouts.
When you implement a (slice) to create a sub-set of data like this, AppSheet uses internal systems to increase efficiency when doing all the โsorting which child records go with which parent.โ
- If you leave it with a brute-force SELECT() like that, youโre forcing the system to work harder than it needs to
The โRelated Distance Checkerโ columns donโt need to be REFโed
I assume the โDistance Checkerโ table was implemented before enum base-type refs were a thing. The references on that table should be replaced with enum columns to remove the unecessary reverse references inside the workstation table.
These are the problems Iโve found with just one table in one sample app.
I wouldnโt assume that what you see in an โofficial sample appโ is necessarily the โrightโ way to go
- Same can be said for โunofficialโ sample apps too
That being saidโฆ I agree with @Steve - using actions for your external links is definitely the way to go.
