Skip to content
This repository has been archived by the owner on Dec 5, 2022. It is now read-only.

Can't use google chart api facade due to missing constructor. #26

Open
sureshg opened this issue Dec 29, 2016 · 4 comments
Open

Can't use google chart api facade due to missing constructor. #26

sureshg opened this issue Dec 29, 2016 · 4 comments

Comments

@sureshg
Copy link

sureshg commented Dec 29, 2016

Generated the js-interop facade for Google visualization api and is missing the imp factory constructors for google chart types. All it has is the fakeConstructor$ instead one with HTMLElement . This makes the generated facade useless. As a workaround, I had to manually add the factory constructors for most of the chart types.

@JS("google.visualization.PieChart")
class PieChart extends CoreChartBase {
  // Manually added this factory constructor.
  external factory PieChart(Element element);
  // @Ignore
  PieChart.fakeConstructor$() : super.fakeConstructor$();

Sample App

I am not sure why we need the fakeConstructor$, is it just to satisfy the inheritance hierarchy?

Also, one of the other major pain point is missing type info from the generated facade.

  /*external void draw(DataTable data, PieChartOptions options);*/
  /*external void draw(DataView data, PieChartOptions options);*/
  external void draw(
      dynamic /*DataTable|DataView*/ data, PieChartOptions options);

Since dart doesn't support method overriding or union types, this dynamic conversion make it less type safe. Is there any plan to fix it?

@kevmoo
Copy link
Contributor

kevmoo commented Jan 4, 2017

@jacob314 thoughts?

@sureshg
Copy link
Author

sureshg commented Jan 10, 2017

Any update would be greatly appreciated. Thanks!

@jacob314
Copy link
Contributor

Issue #1.
Ignore the fakeConstructor$. It was there originally to avoid analyzer warnings and is not the reason why the actual PieChart constructor is missing. I have a CL in progress that fixes the actual issue which is that we aren't matching the JS semantics that constructors from base classes also exist on subclasses.

Issue #2.
Answer depends on what happens with supporting those features generally in Dart code. If Dart supports unions and overloads we will just use that syntax. If it becomes clear Dart will not support them we will look to add custom syntax that only applies for JS interop facades likely using the comment syntax you see now.

@sureshg
Copy link
Author

sureshg commented Mar 23, 2017

jfyi, some of the other TS conversion tools are handling the issue 2 nicely (i mean preserving the type info) .

Eg: TS to Kotlin

external open class LineChart : CoreChartBase {
    open fun draw(data: DataTable, options: LineChartOptions): Unit = definedExternally
    open fun draw(data: DataView, options: LineChartOptions): Unit = definedExternally
}

I hope dart can also solve this issue elegentely 😉

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

3 participants