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
Reduce bundle size by async importing xslx #104
Comments
Hi @stnor, dynamic-import-proposal released with typescript 3.8 hence available with Angular 9.1 onwards. Thanks for the suggestion. |
Great! The longer you can defer the loading the better. In most use-cases I imagine that exporting tables are something the user does very infrequently. I'm on Angular 10 btw, but not using the cli, since I still have one ng1 app entry point left to migrate... |
The package is now depending on |
Thanks! That's great! I'd be happy to fix lazy loading in my app for MatTableExporter. However, I don't really understand how the client should lazy-load mat-table-exporter functionality, given it is a directive, Can you share an example with a mat-table with excel export? I'm using this now: @ViewChild(MatTableExporterDirective) exporter!: MatTableExporterDirective;
export()
this.exporter.exportTable('xlsx', {
fileName: 'foo',
});
} |
It is actually to stay tuned with the |
Btw, the package with minifed version is released as the latest |
That's a shame regarding the lazy loading stance. Even though we just shrunk your bundle size with a factor 10x, it is still unacceptably large for the value it brings given the frequency of table exports in my opinion. I'm not sure it's a good design practice to to use the api of an underlying dependency exposed as your own. I'd rather not have to fork a good and actively maintained project, but hey that's life. |
The exposed type is an extension of xlsx WritingOptions, as you pointed this is an indication of strong coupling between the projects however this is a design decision that has pros and cons and it gives the opportunity of leveraging all the options that xlsx provides through WritingOptions. I'm sorry you had to fork. |
No worries. Thanks for an otherwise great lib. |
It was quite easy. I just made the The imports like |
Sounds great. If it's OK, we appreciate any contribution :) |
If you like I can make a pull request later. As of present I only copied the files into my project and fixed it there. |
Followed the same approach. As you also pointed out, type imports didn't end up in the bundle since they are elided. |
Cool. Sorry, totally forgot that PR.
I’d be willing to test when done.
Let me know!
…On Sun, 25 Apr 2021 at 23:16, Halit Talha TÜRE ***@***.***> wrote:
Reopened #104
<#104>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#104 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEJAD7MIZNZR6N4UM5GUK3TKSBDZANCNFSM42UXR6JQ>
.
|
Thank you for the help :) Btw, with the latest version 10.2.3, you can switch to xlsx.mini.min with something like this:
|
Aw, that's a shame. I don't think the lazy loading will help if that isn't
resolved, as it will both be part of the vendor bundle and loaded again as
lazy.
I've had similar issues when working on lazy loading, but I got it to work
when I copied the stuff I needed from your project.
I always use BundleAnalyzerPlugin to verify, but it doesn't tell you "why"
though.
…On Sun, Apr 25, 2021 at 11:53 PM Halit Talha TÜRE ***@***.***> wrote:
One caveat however, since xlsx.mini.min and xlsx are being imported
dynamically depending on the user preference, webpack happens to bundle
them both. I spent a lot of time to figure a way out but couldn't find any.
I'm always open to new ideas.
[image: resim]
<https://user-images.githubusercontent.com/3686045/116010711-5d0dfd80-a629-11eb-918a-b042e23609eb.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#104 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEJADYF45ETKCZ25DEVGT3TKSFMHANCNFSM42UXR6JQ>
.
|
I'm attaching my changes here, perhaps that can help. |
Oh, sorry for not being clear enough. So this is not the case ;
|
Why is vendor 4MB then? |
Ok, great! Looks good to me!
…On Mon, Apr 26, 2021 at 2:01 PM Halit Talha TÜRE ***@***.***> wrote:
That wasn't a prod build actually, I had just shared to show the lazy and
vendor chunks.
With prod build:
[image: resim]
<https://user-images.githubusercontent.com/3686045/116078759-abf67a00-a69f-11eb-8b4a-609635538c24.png>
And this is the build-stats:
[image: resim]
<https://user-images.githubusercontent.com/3686045/116079011-00015e80-a6a0-11eb-9860-31f3bb5a49fd.png>
If you spot something otherwise, please let us know anyway.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#104 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEJADZETWKR63MCO34CV6LTKVI2HANCNFSM42UXR6JQ>
.
|
Hi,
We find this extension very useful. However it adds 1.4M to our bundle size... Which is A LOT.
It would be great if you could switch to lazy loading.
There is also the "xlsx.mini.min.js" which is a fraction of the size. Won't that suffice?
See some discussion/hints here: SheetJS/sheetjs#694
The text was updated successfully, but these errors were encountered: