Wouldn’t a class on each for all rows also need this class? I’m sure you could work around it without it to do the cells in each row.

Sorry Pat, not sure I follow what you are saying?

What I was proposing was a way to include a unique id and/or css class on the ‘th’ element itself.  This provides a method for being able to style the header cell and/or select it programmatically as needed.

I mean to show/hide columns, don’t we need the ‘tr’ elements to have a class as well?

ah, makes sense now  No, based on my very limited testing, if we hide the th, the entire column goes away.  I haven’t investigated why that is but it must be DOM behavior that hides the corresponding td for any th that is hidden.

Btw, there are risks/downsides to just using “hide” btw.  If the table is editable and if a field is required, skuid will fail required field check since it doesn’t know the elements are hidden as they are still in the DOM.  To properly get this to work, it would be much more complicated then just calling “hide”.

That said, for read-only tables, “hide” would give some primitive ability to conditionally show/hide columns.

I get that. Surely if the option was to make the field conditional and required, then the required field would have to be enabled/disabled as part of javascript that conditionally renders the column. Of course this would only be an issue where the field wasn’t required to begin with and we wanted to be in the component.

Then there’s the whole thing of what makes a column conditionally render. It would have to be something evaluated as one set of conditions for the records in the table and not the individual records. Could be a Condition on the model, a value on the parent record they are all related to, the profile or role of the user, etc, etc.

There is a function on registered lists to removeRequiredField() and there is an requiredFields objects on the list object.

There’s a also a beforeRender() on the list, this is where I’d run the javascript to evaluate the conditions we’d want.

I don’t foresee anything else to get this to work.

Hey Pat -

Great evaluation here.  Let me say that the first focus for this post was to provide a way to more easily identify th elements for styling.  

The added benefit of being able to apply uniqueid/css to a th element is that you can manipulate programatically.  The idea behind using it as a means to hide a column in a table is a complete hack but it would work for some situations.  It wasn’t meant to be a possible long term approach and/or built in to a custom component per se.  

The real need along those lines is conditional rendering for table columns as a stock skuid feature.  For those that haven’t voted for that, vote here - https://community.skuid.com/t/conditional-columns.

In my particular case, I have hundreds of skuid pages and each one will have at least one table where certain columns need to be rendered conditionally based on user preferences/security/etc.  Using the uniqueid of a column to hide was just a primitive attempt at not having to duplicate hundreds of skuid tables just to show/hide certain columns.  Additionally, some columns are based on user preferences so they need to show and hide and the user can toggle realtime.  The lack of support in skuid table for conditional columns is a real shortcoming in the app I’m working on.  Short story is I wouldn’t recommend “hiding” a th even if we have uniqueid/cssclass except for in very specific scenarios and also understanding that it comes with a lot of risks.  That said, and like you said, leveraging other methods to not only hide the column but unregister the field from the list, etc. would be an option - way more complicated to get correct though.