component condition for reduced model quantity

  • 2
  • Idea
  • Updated 7 months ago
  • Under Consideration
I often see pages that have multiple models for the same object. It would be great for page load time to be able to have a condition on the component itself in order to make use of just one model.
Photo of mB Pat Vachon

mB Pat Vachon, Champion

  • 42,714 Points 20k badge 2x thumb

Posted 3 years ago

  • 2
Photo of Zach McElrath

Zach McElrath, Employee

  • 49,056 Points 20k badge 2x thumb
Official Response
Most Skuid data-manipulation Components already have this capability, which we internally refer to as "Data Conditions", available via XML. When you define "Context" Conditions on Components that can be provided with context, you are in fact defining a special type of Data Condition to a Component, just a special type, but we support the addition of other Data Condition types as well --- although currently only via XML. And as you have indicated, Pat, this can sometimes be simpler from a Model perspective because you can just have one Model but then only show certain records from that Model in different Components.

For example, say that you are on an Account detail page, and want to display different types of related Tasks in separate Tabs within the Account detail page, in different Tables, say "Completed Tasks" and "Open Tasks". You could easily have 2 Models to perform this, but you could also just have a single Model to show all Tasks and then have a Data Condition on the Completed Tasks Table to just show records from the 1 Task Model where Status = "Completed" or IsClosed=true, and for the Open Tasks Table show where Status != "Completed" or IsClosed = false. 

However there are many reasons why we have not exposed this capability declaratively via the Page Composer --- there are many common scenarios where the Data Conditions approach can result in somewhat confusing behaviors. Here are some examples:

  • Search - performing a server-side search on one Table will affect all other Components associated with the same Model. This can be non-intuitive and confusing. Client-side search, however, will work well here.
  • Limits on # of Records in a Model / Ordering / Load More - in the Tasks example above, if you limit to 10 records, and order by something like LastModifiedDate, you could very easily have 0 records in your Open Tasks table, even when there are open Tasks, simply because there are more recently-modified Completed Tasks. You'd have to retrieve a very high number of records just to pull in a few Open Tasks. Our "Load More" functionality also is Model-based, so just clicking Load More on the Open Tasks table will not necessarily pull in more Open Tasks, just more Tasks in the Task Model, which is non-intuitive. A separate Model approach is much better here.
  • Filters - applying a Filter on one Table will affect all other Components associated with the same Model. Currently Skuid's Filters are all executed server-side, so there's no way to Filter just one Component without the change applying to all Components associated with the Model that was filtered on.
There are other caveats, but these are the big ones. If you can avoid these, though, Data Conditions can be a helpful tool. Because of these caveats, and because we only support it via XML, we only recommend this approach to customers on a case-by-case basis when it is necessary to achieve desired functionality. One common use case we recommend it for it is to add Conditions that are not supported by SOQL server-side, such as hiding some of the records from a table on an object's Field History based on the OldValue or NewValue field.

In the future we may expose this declaratively, but we have held off on doing so for the reasons described above.