Dataset PCF using FluentUI: Grid Height

This is a part of my blog “My Checklist for a Dataset PCF using FluentUI“. What’s the right height for the grid pcf?

Dataset PCF as a Home Grid

If the PCF is used for the home grid, it is pretty easy: we need to fill in the whole height, and fortunately it works by using pure CSS “height:100%”. The issue here, is to have the header and the footer always visible, while the records are scrolled down, but that’s a problem I’ll talk about in another blog.

Dataset PCF as a Subgrid

For this problem I didn’t had a good solution in the beginning. On the form the height of the PCF is not set, and similar to field-type PCFs, the subgrids are allowed to expand in height as much they want. It’s actually a great feature of PCFs, which we cannot achieve using the old HTMLWebResources based on IFrames. But that means, that we don’t have a base for the height, so the CSS height:100% won’t work. But what’s the right height then? I can imagine 3 solutions, but I like the last one.

1. Using available height

An approach would be to always fill the available height. In case you are looking for this, Scott Durow offered a solution (with codepen demo) in the Community Forum based on CSS (using vh – relative to the height of the view port). Depending on the PCF purpose, it could be a good approach: I’m thinking of calendar controls, or other canvas-based controls. I think that using Scott’s solution, together with the CSS min-height, to stop the control shrinking too much when the browser get’s shrinked, it can work pretty well.

2. Using customized “Number of rows”

But for a grid control, I’d like to try to stick close to the standard grids. They follow the customizing rules, where you can set the number of rows that should be shown.

In order to get close to this, I’ve examined a few parameters that I get in the PCF context (some of them are not documented in the sdk):

  • context.mode.rowSpan
    • Not documented
  • context.parameters.dataset.paging.pageSize
    • That’s documented and sounds pretty much like a friend for my problem:
      The number of records to return per dataset page. On forms, dataset pageSize goes with the formatting (Number of rows) and on others you can choose your personal options
  • context.parameters.autoExpand
    • Not documented, but it seems to be the check box in the image above : “Automatically expand to use available space”
  • context.mode.allocatedHeight
    • Documented, but usually not set for datasets

Here’s the result of the examination for a subgrid:

CustomizingrowSpanpaging. pageSizeautoExpandallocated Height
14 rows, without autoexpand1714falsenot set
14 rows, with autoexpand514truenot set
4 rows, without autoexpand74falsenot set
4 rows, with autoexpand54truenot set
9 rows, without autoexpand129falsenot set
9 rows, with autoexpand59truenot set

It seems that for the subgrids, the paging.pageSize can tell me about the height I should use. The rowSpan is allways 5 if the autoExpand is set, so it helps only sometimes.

What about other places where the grid can be rendered:

CustomizingrowSpanpaging. pageSizeautoExpandallocated HeightCSS 100%
Home Gridundefined25undefinednot setworks
Related Recordsundefined25undefinednot setworks
Dashboardundefined25undefinednot setworks
Canvas Apps125undefinedSETworks

So given this examination, if I want to set the height I have 3 possibilities:

  • allocatedHeight in case is set
  • css: height 100%
  • using dataset.paging.pageSize
    • pageSize * constant + headerHeight + footerHeight

It seems that this could work, in case I can decide if the PCF is rendered as a subgrid or not. Actually only the subgrid works differently: in all other cases the height is given by the platform. But if I don’t have the height right, I risk having 2 scrollbar, which is a bad user experience. So, I’ve decided to go with a 3rd approach.

3. My solution: don’t set the height at all

I like the poster hanging in our office “It’s simple, until you make it complicated” 😉It was exactly the case here.

I had another look at the standard grids. In the home grid (and all the other cases except subgrids), I had to take care that the grid header and footer stays visible, while only the records are scrolled, and that the footer stay down if there are less records:

But if you have a look to the standard subgrids (image below), the header and the footer don’t stay visible, while the footer is shown right below the last record. The subgrid doesn’t have a scrollbar, the scrolling is made by the form:

I remembered that that’s exactly what the FluentUI DetailsList does (before I had to make it learn to work with 100% height).

So if I can tell that I’m on a subgrid, I DON’T HAVE TO SET THE HEIGHT AT ALL. I just let the DetailsList take the height it needs. If I don’t set the height, it will take the height it needs to render the customized number of rows (or less, if there is no paging necessary) and only the form-scrollbars will be shown. Perfect! 🙂

My only problem is: how can I tell that the PCF is rendered as a subgrid or not. The only solution I could come up for now, is using the context.parameters.autoExpand. If it’s not null or undefined, I’m on a subgrid. The decision in my code is looking like this:

if (context.parameters.autoExpand != null ) { 
   //that's the subgrid case
   return <>
//otherwise make the "100%" Grid
<WrapperForDetailsList ...>

Unfortunately that’s unsupported, since autoExpand parameter is not documented. In case you know a better way, please let me know.

I’m not aware of the difference, if the autoExpand is true or false (I think that made a difference only in older CRM versions), so I check only if it’s null or not.

In case you want to have a closer look, I’ve implemented the change to my github repository.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Website Powered by

Up ↑

%d bloggers like this: