Show Component Always

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.

(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.

1 Like

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:

  • Phone_No_Initiate (or Phone_No_Default): a template column or a single value column, whose value will be non-empty for each new row. For example – or - .
  • Phone_No_Submit: basic column whose value is submit by the user.
  • Phone_No_Display: an if-then-else column to display Phone_No_Initiate if Phone_No_Submit is empty, else Phone_No_Submit.

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:

  • If Phone Number is empty, then ‘-’
  • Else Phone Number
1 Like

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:

  • I use three columns for images and I prefer being consistent with my methods. If I do it for images, I’ll do it for other data types as well.
  • I like seeing my data in tables. That way I might remember it’s there. I would feel uncomfortable if default data were “hidden” in a field of a ITE column. But maybe that’s just me :sweat_smile:
1 Like

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.

1 Like

Hm…good insight on magic numbers. Apparently I use magic numbers all the time…might need to rethink my methods.

1 Like

hehe yeah, I’ve picked up on that in some of your videos but didn’t say anything :slight_smile:

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 file that contains declarations for all my global variables, including any “magic numbers”. So I might have stuff that looks like this:

// Magic Numbers

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 : )

1 Like

Hehe. It’s like the “answer to everything”…I should have went with 42 instead. :wink: 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 : )

1 Like

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 :stuck_out_tongue: (and you could probably call that a “Magic Column” :rofl: )


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 : )

1 Like

@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 :rofl:

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.

1 Like

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 :wink: 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 :slight_smile: