Option 1 should work decently for now, and I will create a feature request to get a isAddRow property added to cell.row. Thanks for the help.

I understand that I can access isAddRow via that event, however, that's not what I'm trying to do at all. What I'm trying to do is something like this, in order to mimic what's in the cell.component.html from the GitHub, and conditionally render things in the HTML based on something like this (please note that I KNOW that cell.row.isAddRow does not exist, but I need something LIKE it. I'm asking if there's ANYTHING on the cell template variable that can help me deduce if the row is a new row):

	
		{{ cell.row.isAddRow && !val ? cell.column.header : (val | lookup: dataTypesLookup) }}
	

While this solution may work, it's a bit of a hack in my opinion. I shouldn't have to modify any values to be able to tell if a row is a new row or not. I should be able to determine that through the igxCell directive. What would be ideal is being able to say something like: cell.row.isAddRow, and be able to render different information based on that.

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.