Why IgxTreeGrid behaviour isn't a feature of IgxGrid?

[luiscla27]

Question

I want to know the cost of using IgxTreeGrid everywhere instead of IgxGrid, And why not you just add a flag to IgxGrid so the tree behaviour is enabled?

I've found only three differences between both implementations:

• groupingExpressions which is implemented as a pipe for IgxTreeGrid, but for IgxGrid is implemented as an attribute.
• dataPreLoad event exists at IgxGrid but is not present at IgxTreeGrid (Is not clear to me why)
• childDataKey attribute is required for IgxTreeGrid to work, it doesn't matter if it's value is undefined

I see no problem with changing all my implementations from IgxGrid to IgxTreeGrid, my only concern is that there must be a really good reason for you to keep them as a separated components.

What I mean is that an IgxTreeGrid implementation seems to have all the features of IgxGrid but with a plus of being able to add sublevels. So, I'm wondering; is there's something wrong if I just forget everything about IgxGrid and just start using IgxTreeGrid everywhere?

The only obvious thing I can come off is that IgxTreeGrid is slightly heavier than IgxGrid, but that doesn't seems to be enough reason for the separation (I might be wrong and one might be way heavier than the other).

• igniteui-angular version: 12.1.8
• browser: Chrome 95.0.4638.69 (Build oficial) (64 bits)

[ChronosSF]

Hey @luiscla27 ,

Separating the components allows for two important things - smaller bundles and API clarity. Even if you don't use a certain feature of tree-grid, it is part of the component and therefore you get it in your bundle. There is no reason to further increase that bundle size by adding all the other features that are simply not supported.

Another important aspect is that this allows us to only include the API that is supported. So that you are not allowed to e.g. add Details template and assign Master-details related properties when tree grid doesn't support these. It's much better UX to not have this API in the first place than having to explain when and how it can be used, add checks, warnings, errors, etc.

[luiscla27]

Thanks so much for your quick answer @ChronosSF,

The reason I'm asking this is because I wanted to encapsulate much of IgxGrid implementation into TS code, instead of doing this:

<igx-grid [data]="data" [displayDensity]="displayDensity" [emptyGridMessage]="emptyGridMessage" [exportExcel]="exportExcel" ... many more attributes>
        <igx-column ... a lot of attributes></igx-column>
        <igx-column ... a lot of attributes></igx-column>
        <igx-column ... a lot of attributes></igx-column>
        <igx-column ... a lot of attributes></igx-column>
        <igx-column ... a lot of attributes><ng-template igxCell>...</ng-template></igx-column>
        <igx-column ... a lot of attributes><ng-template igxCell>...</ng-template></igx-column>
        <igx-column ... a lot of attributes><ng-template igxCell>...</ng-template></igx-column>
        <igx-column ... a lot of attributes><ng-template igxCell>...</ng-template></igx-column>
</igx-grid>

I'm trying to encapsulate much of the grid definition into the ts file by using an hypothetical helper called GridBuilder, something like this:

ngOnInit() {
    GridBuilder.init(this.gridConfig)
        .push(new IconColumn('column1', ...))
        .push(new TextColumn('column2',...))
        .push(new DropDownColumn('column3',...))
        .push(new CustomHTMLColumn('column4',...))
        .push(new DateColumn('column5',...))
        ...
}

And my template would look something similar to this:

<my-encapsulated-grid-implementation [gridConfig]="gridConfig"></my-encapsulated-grid-implementation>

The reason I 'am considering to do that is because this approach will give me the benefits of polymorphism (and every class inheritance benefits you could think of), this would give me a huge advantage of scalability for my application. A quick example, let's say in my application I have 5 common auditable columns between all my entities, lets say "name", "created by", "creation date", "last modified date", "last modified by".

With the TS definition I just explained I would already have all the code I need for a "base grid", the only thing I would need to vary from one implementation to another is the REST API from where I gather my data, and maybe add more columns, something like this:

ngOnInit() {
    super.ngOnInit(); // <--- The "base columns" would be defined inside the extended class
    GridBuilder.init(this.gridConfig)
        .push(new IconColumn('column6',...))
        .push(new DateColumn('column7',...))
        ...
}

What this means is that I would be able to create a lot of views querying different items with almost no effort at the frontpage.

I wanted to explain you all this because maybe you can give some suggestion you could think of (that maybe I'm being blind to), my current main issue and the one I'm trying to address is that if want to have support for the IgxTree sublevel features, I would need create two templates that would look basically be the same, with the only main difference of the IgxGrid tag vs the one for IgxTreeGrid, this will destroy my purpose of reducing maintainability costs because everytime a breaking change comes out (or a new feature) I would need to fix it in at least two places.

But forgetting everything I just said and assuming not much can be done, my best option seems to just use IgxTreeGrid everywhere instead of IgxGrid, aside from the things you already said is there something else I should consider???

[ChronosSF]

I suppose you'll ngFor the column collection in the underlying grid template? The issue I can see is that you can't really assign column templates like this.

I don't see a huge issue having two encapsulation templates for the two grids. You can have it very minimal and assign most things through setters instead of the template (columns being the biggest exception from the rule).

Apart from that the only issue you may have is if you want to use GroupBy as that works differently for igxTreeGrid. You can't use Master-Detail-style visualization in igxTreeGrid either. Performance should generally be comparable.

[luiscla27]

Yup, I'm iterating the columns array using a ngFor, I don't need templates because the definition for every possible template I may use is defined there, every constructor I mentioned is already defined and if I need more I can just add support to it there (new IconColumn, TextColumn, DropDownColumn, CustomHTMLColumn, DateColumn, etc.) for specially handcrafted templating I was planning to use SafeHTML and inject directly anything I may need (mostly links, images).

This is the answer I was looking for:

Apart from that the only issue you may have is if you want to use GroupBy as that works differently for igxTreeGrid. You can't use Master-Detail-style visualization in igxTreeGrid either. Performance should generally be comparable.

However, you're right (as you already stated) for some reason I completely forgot the possibility of assigning everything using setters. That totally solves my issue. Thank you so much.

I don't see a huge issue having two encapsulation templates for the two grids. You can have it very minimal and assign most things through setters instead of the template (columns being the biggest exception from the rule).