-
-
Notifications
You must be signed in to change notification settings - Fork 533
DataGrid: Export: Architecture, csv exporter, external binary data exporter #6067
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
… (bson) exporter.
There are many things to review here. But overall I like the approach that will help us to extend it, and with minimal changes to DataGrid. I will properly review it later but for now I would like to focus more on high level architecture.
|
Hmm. Ok, so now
Also, there's no place anymore for The common export logic has been moved to the |
Yeah, I think this might be a better approach, as Blazorise core might become too bloated. So have:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are quite some inhertiance going around. I'm still trying to unwrap it in my head...
Description
Closes #6042
This pull request introduces a new exporter architecture for the DataGrid component.
As part of this architecture, I've also included two example supported formats
Csv
– a text-based format that is bundled in theBlazorise.DataGrid
package.Bson
– a binary format that is simple to work with and demonstrates external extensibility. It requires an additional dependency and is implemented in a separate project (Blazorise.DataGrid.Exporters
). (This is where Excel exporters should go too).While the new architecture is not small, it enables a powerful level of extensibility. Creating a CSV exporter, for example, could be done with much less code — but the purpose of this system is to ensure external exporters can be plugged into DataGrid easily.
With this architecture, no changes are needed in the
Blazorise.DataGrid
core codebase to support new exporters. A developer only needs to implement a single abstract class, focusing purely on the core export logic and options. Thanks to these design choices, the boilerplate for creating a new exporter (e.g. a potential JSON exporter) is reduced to a minimum (see theBsonToFileExporter
).While developing the architecture, I also re-evaluated what "export" should mean in the DataGrid context. It doesn't have to mean only exporting to a file — it can also mean exporting to a string (TextExporter), the clipboard, or any other target. Currently, we support 3 targets:
This concept of "targets" opens up future extensibility such as:
(Many of these could work with the simple
TextTarget
or minor variations of it, so I din't go much deeper)Nomenclature
CsvToFileExporter
. This is why theCsv
directory contains multiple files — it supports multiple targets.Getting data from DataGrid
This area still needs improvement, as my knowledge of the full DataGrid capabilities is limited. Currently, only columns with a defined
Field
are exported, and the value is either formatted (for text) or raw (for binary).One potential future enhancement:
A property like
BaseDataGridColumn.Func<object, object> ExportValue
could be used to customize how each column is exported — giving the developer full control per column.The data passed to exporters is structured as a
List<List<object>>
orList<List<string>>
, depending on whether the export is binary or text-based.Usage
As simple as:
As shown above, only one public method in
DataGrid.razor.cs
is needed to support all export formats and targets.Blazorise.DataGrid.Exporters
is an external test project designed to validate the extensibility of the exporter system. It serves as a foundation for future projects where we'll support additional exporters that require external dependencies (e.g., Excel). It can be merged in this test form - it does nothing wrong.