For all components please allow an option to have the component appear even if there is no data in the field. The UI changes depending on what data has or has not been entered, which makes it harder to make consistent screens. And also, when viewing, the user may not know which fields are missing data simply because they do not appear. But it would be good to see something like this to show that some data is expected but not entered.
Status:
(empty space)
An alternative would be to remove headings from all of your components, but instead use text or rich text components as your headings.
Another alternative would be to initiate you data points.
Letâs take âphone numberâ as an example. It could be anything else you expect your users to submit.
You can create 3 columns:
With these 3 columns â initiate, submit, display â you can make sure a default value or a submitted value are always displayed.
This column is actually redundant. You could just use a single if-then-else column, ie:
Totally agree, three columns could be reduced to two, but I prefer not to. I use this method quite often, mainly for user-submitted data thatâs not required, including images. For images, Iâll use the âGenerate Imageâ column (only if the list is short, because the experience may become sluggish if the list is too long) or a single value column with a URL.
Reasons why I always use three columns even though I could simplify:
This is a good point. And itâs similar to the mantra of avoiding Magic Numbers in programming.
Personally I think itâs okay for this specific use case, but I totally get your approach and donât disagree with it.
HmâŚgood insight on magic numbers. Apparently I use magic numbers all the timeâŚmight need to rethink my methods.
hehe yeah, Iâve picked up on that in some of your videos but didnât say anything 
I think with Glide, itâs probably a matter of striking a balance between avoiding it and winding up with an excessive amount of columns.
But when it comes to coding, I try to be a bit disciplined about it. For example, when Iâm writing Apps Script for a project Iâll usually have a separate constants.gs file that contains declarations for all my global variables, including any âmagic numbersâ. So I might have stuff that looks like this:
// Magic Numbers
const SCREENINGS_RESTART_THRESHOLD = 10; // Minutes
const GANG_LIST_BUFFER_DAYS = 14;
const ROSTER_BUFFER_MONTHS = 6;
It takes some discipline, but pays dividends when you come back to the code several months later and try to debug something.
I like that concept a lot! Iâm no programmer I had never heard of magic numbers before, but we do see them quite a bit.
Do you consider the +15 or +15+30 from the first day of the month to be a magic number? The first time I saw Jeffâs method, I found the approach both really smart and uncomfortable: 15 is somewhat arbitrary I feel, any number between 1 and 27 would work fine really, but 15 feels far enough from the edges : )
Hehe. Itâs like the âanswer to everythingââŚI should have went with 42 instead. 
The reason I went with 15, is that it puts you approximately in the middle of the month, so when you add months or years based on the average number of days in a month, it would keep you somewhere in the middle of the resulting month. I just wanted to allow enough wiggle room since the math could add a day or two before or after the middle of the month. Adding 30 days to the first or last day of a month can give you inaccurate results since months can have a varying number of days. I think some earlier versions of my formula werenât quite as accurate, but the latest version is pretty solid I think.
Yeah it is a bit arbitrary to use 15. Itâs less of a magic number, and more of a throw spaghetti at the wall and see what sticks. The formula is not easy to understand, but I like the challenge of throwing everything into a single math columnâŚeven some semblance of IF logic, using creative math. Breaking it down into multiple columns would definitely make it easier to understand several years from now.
I find the formula and thinking behind it incredibly smart, donât get me wrong. I was just wondering if we could put that +15 in the magic number category : )
Iâve been thinking about this all day, and I donât really have a good answer. Iâm inclined to say no, but I donât know how well I can explain why. I suppose, you could extract the 15 from the formula and put that in its own column, but what do you call it? Magic 15? That wouldnât be very helpful.
In this case, I think what is way more important is how you name the column that itâs used in. In any Math column where you use a complex formula, you better make damned sure that the name of the column makes it absolutely clear what the purpose of it is. Throw one of Jeffâs date formulas in a math column and call it Date2 or New Column 7, and you deserve what you get 
(and you could probably call that a âMagic Columnâ 
)
Right?! +15 fits in the formula perfectly, itâs bring us to the âmiddleâ of just about any month, 15 is so much prettier than 14 or 16. But then, 15 is so arbitrary. Your column would be called âMiddle_of_Month_Incrementâ, but then the column would just contribute to column bloat, and really the fewer columns the better in my view : )
@Jeff_Hager Context on the Magic â15â please. Can you reference where this approach is? I always like seeing other approaches. Especially date related things.
Maybe this oneâŚ
Actually, from the same thread⌠I think this was the very first time JeffChuck unleashed the magic 15. Iâll never forget it. He did in one column what had taken me more than 40 columns
And, if you like date related stuff, have a browse through this threadâŚ
I think this is the latest iteration of the formula to add months to a date, which handles leap year or end of month situations.
I think one thing to consider with magic numbers is, could they ever change. Consider a tax rate, for example. Sure, you could just make tax part of a formula to add a certain percentage of tax to a total, but thatâs a number that could potentially change every few years. On the other hand, it pretty safe to say that the number of days in a month wonât change in any of our lifetimes.
Another consideration is how often that number is used throughout an app. If the number is used in several places, then it probably makes sense to have it as a global variable. Then in the event that you ever need to change that number, you only need to change it in one place.
Itâs a matter of how easy you can make it to find and change a number in the event that you ever need to in the future. Whether itâs well labeled variables, or very thorough documentation.
Think of how glide uses CSS. They most likely have a master CSS stylesheet that controls the CSS for all apps. Whenever they want to make a change to how a component looks, they only have to change it in one place and every single one of our apps is automatically updated. On the other hand, when one of us chooses to add CSS which overrides the CSS from that master stylesheet, then it only affects one screen in one app. Magic numbers are really the same. They can either be a global defined variable, or they can be super specific to one little section of a function or formula.
In the code world, documentation is key. Whether itâs naming variables in a way that tells the developer their type and purposeâŚor simply adding comments to your code which describes what a function does and how it works. A lot of times you need to consider that someone else will have to look at that code and make sense of it years in the future.
At my day job, I work as a developer. There are some wicked math formulas that we deal with, that are provided by the government. Some of it uses lookup tables with millions of records to get specific variables for math formulas, some of it uses static numbers that never change, and some of it uses global variables that are used in multiple calculations. Itâs kind of all over the place, but in most cases everything is well documented so we can match up the code to the specs when needed. Through the years, a lot of our code has been updated to use table driven variables, so itâs a lot easier bto make the code run differently by changing some values in a table. The most frustrating part though, is when Iâm looking into a bug, but I run across code that was added 10 years ago with little to no documentation. I end up spending a lot of time trying to figure out what the code is supposed to be doing, so I can then figure out how to fix it. It can be very time consuming.
In the end, just make sure you can look at something several years from now and easily understand what itâs doing so you can maintain it if necessary.
To decide whether to give the number its own cell or column in a table, I like Jeffâs recommendation that it depends on whether the number might change and how often it is used throughout the app.
Like you Darren, Iâve been thinking about this a little, and Iâve come to the conclusion that 15 is not a magic number, but a constant of nature just like pi or e This constant represents the middle of a month or half a month, so we can happily name this constant hm. This conveniently also refers to her majesty. So hm is not a magic number