I'm evaluating purchasing Ignite-ui for a project that my company is working on, and I have a few questions about the igx-grids:
Responsive table stacked example:
Hello,
I have been looking into your questions and what I could say regarding the first one is that validating rows should be handled entirely on application level using the exposed grid editing events.
Regarding the second question an approach I could suggest in order to hide the column headers is to set the display attribute of igx-grid-header-row to 'none':
:host { ::ng-deep { igx-grid-header-row { display: none; } } }
A small sample that demonstrates this approach could be found here.
Regarding the third question, in order to achieve your requirement, my suggestion is to use the igxCell directive and based on the grid's width you could define a different template. Also, via the exposed column's hidden property you could hide or show a certain column based on the grid's width or some other conditions. I have prepared a small sample that demonstrates how such behavior could be achieved and it could be found here. Please test it on your side and feel free to modify or style it based on your requirements.
Another possible approach to determine the grid’s size within the ts file would be using the ResizeObservable. In general, both approaches should be implemented entirely on application level.
In addition, more about grid templates could be found here.
Regarding your last question what I could say is that in order to keep the public API simpler for using and understanding we do not expose all services, interfaces or methods which we are using for implementing the build-in functionality. Using the already exposed properties gives you the opportunity to implement different requirements and scenarios without breaking the functionality of the components.
Also, from version 12.1.0 IgxGridCellComponent, IgxTreeGridCellComponent, IgxHierarchicalGridCellComponent are no longer exposed in the public API. Instead, a new class IgxGridCell replaces all of these. It is a facade class that exposes only the public API of the above mentioned and CellType is the interface implemented by IgxGridCell, so you could use it as well as RowType, etc. for typescript typing. For example, the following is a completely valid code:
const rows: RowType[] = this.grid1.allRows();
Additionally, please keep in mind that according to our support policy we handle a single question per case. This is for better consistency and history tracking.
If you require any further assistance on the matter, please let me know.
Sincerely,
Teodosia Hristodorova
Associate Software Developer
With the cell.rows.cells property in the example for a stacked layout, is there anyway to get access to the parent IgxGridCellComponent for each cell? There is a getter called template that I would really love to use in an ngTemplateOutlet, so that I could just show the cellTemplate/cellEditTempalte for each column. I would use the cellTemplate property on the cell.column, but that wouldn't exist for columns that are using the default template. I want to be able to use this layout for grid editing as well, if possible.
The examples for hiding a column header and showing a stacked layout should fid my needs sufficiently. I had no idea about the cell.row.cells property, that definitely makes the code quite nice -- that's neat.
It's a shame that there isn't any built-in grid validation services to opt into, but I will make use of the editing events.
I can definitely understand that you don't want to convolute the public api with things that could potentially allow customers to shoot themselves in the foot. It sucks for the power-users, but I can definitely understand. I would still request to have the interfaces exposed in one form or another, even if it were through a secondary entry point like: "igniteui-angular/interfaces" or something. That way it wouldn't convolute the public api for the majority of people, but would provide nice type checking for people who are going to create wrappers/directives around your components, since interfaces have no impact on runtime.