Property filter does not exist on datasource when using table schematic

[landonwaldner]

Bug, feature request, or proposal:

When generating a table schematic, datasource is extended instead of MatTableDataSource. Because of this, the filter method is not available to set up table filtering.

What is the expected behavior?

Extending MatTableDataSource so that filtering may be applied to the table

What is the current behavior?

Filter function not available because generic datasource was extended in x.datasource.ts

What are the steps to reproduce?

ng new table-project --style scss --routing
code cip
ng add @angular/material
ng generate @angular/material:material-table --name table
Add below function to table.component.ts:
applyFilter(filterValue: string) { filterValue = filterValue.trim(); // Remove whitespace filterValue = filterValue.toLowerCase(); // MatTableDataSource defaults to lowercase matches this.dataSource.filter = filterValue; }
Intellisense indicates that filter function not found on datasource

What is the use-case or motivation for changing an existing behavior?

Need to be able to apply table filtering when using schematics

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

"@angular/animations": "^6.0.3",
"@angular/cdk": "^6.2.0",
"@angular/common": "^6.0.3",
"@angular/compiler": "^6.0.3",
"@angular/core": "^6.0.3",
"@angular/flex-layout": "^6.0.0-beta.15",
"@angular/forms": "^6.0.3",
"@angular/http": "^6.0.3",
"@angular/material": "^6.2.0",
"@angular/platform-browser": "^6.0.3",
"@angular/platform-browser-dynamic": "^6.0.3",
"@angular/router": "^6.0.3",
"core-js": "^2.5.4",
"rxjs": "^6.0.0",
"zone.js": "^0.8.26"

Is there anything else we should know?

[andrewseguin]

@amcdnl Who has context about why we chose to implement a data source rather than use the built-in MatTableDataSource.

[amcdnl]

@andrewseguin - We wanted to show how to do all the internal yourself so that you can easily hookup to backend services rather than just use the client side features. I believe the majority of cases will be doing this.

@jelbourn - What do you think? Should we switch to use the MatTableDataSource that encapsulates most of this?

[jelbourn]

My thinking is that using a separate data source teaches the user how they should structure their code (separation between data manipulation and display).

[amcdnl]

OK, @jelbourn - we ok w/ closing this then?

[jelbourn]

I think so. Andrew's out-of-office so he won't be weighing in further

[gitneeraj]

What's the fix for this, guys?

[GCSDC]

Rewriting the entire implementation for the DataSource seems to be completely opposite to the goal of using material components.

Why not providing both schematics with full functionality (including filter)?

1. Using custom DataSource class: for server side handling, as mentioned by @amcdnl
2. Using MatTableDataSource: for client side handling

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}