-
Notifications
You must be signed in to change notification settings - Fork 193
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
ES6 import instead of polluting global namespace #123
Comments
The main use case is actually: import { EChartOption } from 'echarts';
// ...
export class MyComponent {
activityChartOptions: EChartOption;
} |
@smnbbrv If we imported echarts in our directive, the echarts' codes would be bundled into our library. It's unnecessary, more like a disaster.
That's why you need to install echarts first when you use ngx-echarts. Meanwhile, you can upgrade echarts as you wish without waiting for a new version of ngx-echarts. |
@xieziyu sorry, I don't understand... I don't offer to bundle the specific version of echarts inside of ngx-echarts.
Why do you think so? Angular heavily uses rxjs which they internally import literally everywhere but it is not bundled into e.g. @angular/core. Another example: I am an author of https://github.com/SortableJS/angular-sortablejs. I use original sortablejs library inside as a normal import and also install it separately from the binding library. The versions are not anyhow restricted (only in package.json |
@xieziyu please check my fork in the related pull request and feel the power of typings :) then try to build the library and look into the dist folder: there is no original library there. |
@smnbbrv I will leave comments in your PR. |
you are welcome. You should not offer excuses, I know the real pain of supporting the binding lib between two other libs + frontend develops so fast that it is really hard to be up-to-date everywhere. That's why we have open source :) If you need any further help, feel free to share! |
Looks good to me. Is it already published under |
Sorry for the late response. I published it just now. |
No problem :) Added a small readme pull request. I just tested everything, looks super! Thank you very much! I faced a small issue with the library @angular/flex-layout but I will open another issue because it is unrelated here. |
Hi @xieziyu ,
thank you for beautiful project!
I have a question concerning the setup.
README: https://github.com/xieziyu/ngx-echarts#how-to-use-it-within
And all lines like
ngx-echarts/projects/ngx-echarts/src/lib/ngx-echarts.directive.ts
Line 9 in 4852a0a
This is what I find a little bit dirty. I can't use typings from original
echarts
to use it with options etc.Also it creates issues for the people like #119. They need to redeclare the variables on their own instead of simple
I have a working solution with typings, normal import from
echarts
and fully-functional AOT (if this is the reason of all listed above).I just want to ask you before making a pull request: is it helpful? Is there any reason why we should go on with dirty importing?
The text was updated successfully, but these errors were encountered: