mgt-file-list component should have filterFiles property to be able to use a custom filter

[eduardpaul]

Proposal: Add filterFiles property to mgt-file-list so custom filter function could be provided by consumer

Description

As a consumer of this component i should be able to decide if specific document should be shown or not (currently only file extensions are supported). Using a filter function could solve most scenarios.

Rationale

• Use case: include all extensions except ".json". Not possible with current component.
• Use case: exclude specific folder or file by name pattern.
• Use case: exclude by other DriveItem properties (filesize) or combination of properties (ex.: .back files if size is > 1gb)
• It could help to solve (or provide workaround) mgt-file-list should support both filtering by file extensions but also return folders #1749
• It will be a similar approach as filterTasks property

Preferred Solution

Implement filterFiles property following the filterTasks implementation from to-do component.

Additional Context

Probably I will try to implement it myself any time soon.

[sebastienlevert]

Thanks for your suggestion! We'd love to work with you on this request. Right now, the filterTasks on the to-do component does the filtering on the client side, which is OK for tasks as the amount of data is limited, but challenging for a file list. Today, we already support providing one of multiple file queries, but these won't support advanced filtering, and the search endpoints on the drive items is being deprecated, so this doesn't help in the future (https://devblogs.microsoft.com/microsoft365dev/transition-to-microsoft-graph-search-endpoint-for-onedrive-and-sharepoint/).

That being said, there are valid scenarios and would love your feedback. Is it more of a "search" scenario that could leverage an improved version of our search results component? Would client-side filtering "enough" for this concept? Let's brainstorm!

[eduardpaul]

@sebastienlevert totally agree with you that client side filtering is not the best option to filter out results and it could be a pain when it comes to paginating results from graph api.

Our scenario is more about file management where we want to hide specific files (system files) from the end user and allow them to browse through folders and upload files. In SharePoint Online we are handling this by filtering certain content types in the list views. In this case, client-side filtering of file-list will do the trick.

One thing I'm not sure about is if it makes sense that the file-list component should have the file upload option. For example it generates an inconsistency with the configuration: if you activate upload and configure filequeries you will be showing documents from one place but the upload will be done in your onedrive. And as you pointed out, listing files (read-only scenarios with search, filtering,....) could be covered by a search-result component.

Probably in the long term it would be better to have a "file-explorer" or "file-manager" component with some basic add/upload, delete, move, copy and paste functionality that you could point to a specific library, folder,. and replace file-list with search result component.

[sebastienlevert]

To your last point, we have been having a long-standing PR that does exactly what you are mentioning (minus the file filtering). #2564

It might be useful to look at this branch (very outdated to be honest) and see if this could help with your scenario.

Now back to the file filter scenario, I think it makes sense for "light" filters, maybe not large complex filters... I think we could document this caveat and I'd agree it deliver some scenarios... We're happy for you to send a PR and we'll happily review and help with the process!

[sebastienlevert]

At the moment, this is not something we're likely to prioritize. That being said, the Graph Toolkit is an open source project and we'll be happy to support and review if you want to contribute to its codebase! Please let us know if you'd be happy to help and implement this capability. If not, it's absolutely fine, we'll go and close the issue and might re-open it later if we reconsider our priorities. Thanks!

[microsoft-github-policy-service]

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.