Is it possible to use the new v41.0 lightning:outputField in huge numbers inside tables? Is it possible to extend it?

Today I’m giving the new v41.0 <lightning:outputField> a try. I want to use it massively inside an <aura:iteration> to build a data-table and want to accomplish the following:

  • Internationalized output: correct decimal delimiter, correct date and number formats. Tried lightning:formattedNumber does not work as expected, because it takes the settings of the browser, but I need to use the the users salesforce locale not the locale defined in the browser). Basically this is done very good by <lightning:outputField>. Exactly as expected!
  • Eventually I want an editable table with picklists, transaltions, lookups all the good stuff, you name it. And high numbers of it. So I would like to switch to <lightning:inputField> in the end. But as starter Read-Only is good enough.

I would need to adjust several things of <lightning:outputField>. The mode variant="label-hidden" helps but is still messing things up in my layout. Therefore I thought about to extend and customize the component as described here:

https://developer.salesforce.com/blogs/developer-relations/2015/03/salesforce-lightning-components-by-example-component-extension.html

1. Is it possible at all?

I have tried this:

<aura:component extends="lightning:outputField">
    <!--...-->
</aura:component>

But when I want to save the markup, I get only

FIELD_INTEGRITY_EXCEPTION

cannot extend non-extensible component

2. Are Standard Components extensible at all?

Are some / all or none of the Salesforce-Standard components (those of the namespaces force:, ui: and lightning:) extensible="true" or not? Where (documentation, documentation-app, etc.) can I find if and which component is be extensible or not?

3. Even if it would be possible, is extension a good idea?

The rendering of the component is not inline. It creates several display:block; and inline-block; elements in the DOM. This is messing-up my layout (huge table, lots of lines, lots more of <lightning:outputField>). Now is extension a good approach to make something which fits only partly better fit into the requirements? The partly good fit is localization: <lightning:outputField> comes in good old Visualforce quality I was used to from <apex:outputField>! Perfect!

4. Slow and async rendering

To use lightning:outputField inside a table and inside an iteration over the <tr> I was only able to do it like this

<tbody>
    <aura:iteration items="{! v.Opportunities }" var="item">
        <tr>
            <td>
                <lightning:recordViewForm recordId="{!item.Id}" objectApiName="Opportunity">
                    <lightning:outputField fieldName="CloseDate" variant="label-hidden" />
                </lightning:recordViewForm>
            </td>
            <!-- !! lots more of outputFields to come ... !! </td>-->
        </tr>
    </aura:iteration>
</tbody>

I would have preferred to have only on single <lightning:recordViewForm> per <tr> but this is messing-up the table layout completely. That’s the reason for lots of <lightning:recordViewForm> per <tr>. It works, but I need massive CSS-hacks to adjust the rendering and it becomes very slow and does not scale good.

5. Is <lightning:recordViewForm> designed to be used in high numbers?

All this looks and feels like <lightning:recordViewForm> is designed to be used only once or at least only in a very small number of occurrences per component or page. I did not see it stated in the docs, but is I my feeling correct that it should be used only a few times and not a couple of hundred times? If so, what is the best practice for such tables?

Answer

  1. Is it possible at all?

No.

  1. Are Standard Components extensible at all?

No.

  1. Even if it would be possible, is extension a good idea?

It’d be potentially useful, but we can’t.

  1. Slow and async rendering

You shouldn’t be using tables. It’s a shame that they actually allow it, because tables are not used anywhere in Lightning at all. Everything is meant to be responsive, and tables are not responsive by nature. You didn’t say exactly how your layout got messed up, but you should look at the lightning:layout element to create a grid that can reflow elegantly with fewer CSS hacks.

  1. Is <lightning:recordViewForm> designed to be used in high numbers?

The documentation doesn’t say, but I’d have to guess “probably not.” You might consider using force:outputField/force:inputField instead. I’ve had much better luck using combinations of lightning:layout and lightning:layoutItem. This give you better control over how things are laid out.

Also, I’d solidly recommend pagination if you’re looking at more than ~25 items. Actually, using pagination or infinite scrolling might be a better idea anyways; the data could load progressively so that you can minimize the rendering time.

Attribution
Source : Link , Question Author : Uwe Heim , Answer Author : sfdcfox

Leave a Comment