See the code in src/applications/project/controller/PhabricatorProjectBoardViewController.php: The $columns result is created on the fly so checking first whether columns with PhabricatorProjectColumn::STATUS_HIDDEN exist (and caching that result?) might make things slower. If my code understanding is correct.

Caching is a good idea. The state won't change often.

I think there are two possible changes we could make here based on the task title. It's not entirely clear to me which is being suggested:

1. Remove the menu item completely if the board has no hidden columns.
2. Retain the menu item, but render it in a disabled / greyed out state, if the board has no hidden columns.

We are very unlikely to remove the item completely. When we completely remove actions a user does not have permission to take (or which can not be taken given the current state), it tends to very slightly streamline the UI for experienced users (a small benefit) but make the UI much more difficult to navigate for less experienced users (a huge cost). Particularly, it means the UI can not answer these questions for less-experienced users on its own:

• Is action X possible at all?
• Why can't I take action X right now?

These are common and reasonable questions that less experienced users often have, and consistently showing actions (but disabling them if they are not currently available) usually allows less-experienced users to find the answers themselves by exploring the UI.

Even for experienced users, the benefit of streamlining the UI may be small or even nonexistent: when options are removed, it means the positions of options change in a context-dependent way -- which can make interacting with menus slower, because you can't rely on positional memory as much. And even experienced users sometimes want to know "Why can't I take action X right now?".

Still, we could disable this item if there are no hidden columns on the board. However, my first reaction is that this wouldn't be a very good change, either. Here's my thinking:

From my perspective, this action is similar to changing the ordering or the query filter on a board with no tasks: even though the UI doesn't actually change, the action adds a configuration parameter to the URI which may be useful if you want to link to the board in a certain state, or you anticipate modifying the board state.

We let you change a board with no tasks to have "Order by: Priority" or "Order by: Owner", and we let you change a board with no tasks to have different query filters. This seems like a pretty similar operation to me: you're changing the view parameters of the board, and that's a legal and sometimes useful operation even if the new parameters don't currently produce a different rendering result.

Stepping back a little bit, I'm not totally sure what the root problem we want to solve here is. Maybe:

• "I only expect the UI to show currently available actions." - We consistently show actions that are not currently available because this allows the UI to answer important questions about why those actions are not currently available.
• "I only expect the UI to show this action if it will affect the view." - This is reasonable, but I think this action is similar to the order/query actions. If this is unintuitive, perhaps we could move the item to a different menu (with other view filter actions) to try to reinforce that it's being treated a "view parameter" action.
• "There's no way to tell if a board has hidden columns or not, so I have to go click the action and see if anything shows up." - This is very reasonable, but not entirely clear from the problem description. If this is the root problem, I'd consider adding a separate indicator to show this state. One simple version might be to relabel the action to "Show Hidden Columns (3)", although if this information is reasonably important I'd probably be inclined to look for a solution that doesn't require you to open the menu to see that columns are hidden.