Diego Esmerio

What about the new hook feature? Can it be a better fit here?

> got [errors that I should call it inside the body of a function component](https://reactjs.org/warnings/invalid-hook-call-warning.html#breaking-the-rules-of-hooks). > > This is where I am right now: https://github.com/stroborobo/Fulma/tree/datepicker-react-hook Probably that can be fixed...

[Dartdoc](https://github.com/dart-lang/dartdoc) is the tool that generates [this kind](https://api.dart.dev/stable/2.17.0/dart-collection/Queue-class.html) of documentation and the ones on pub.dev that already describes the public API for each library. Looking at the html it generates...

When importing the dartdoc package, we can create a `Dartdoc` instance calling the constructor `Dartdoc.withEmptyGenerator`. There is a brittle `generator` field on it with a `@visibleForTesting` annotation that we could...

I upload the test file I made in [this repository](https://github.com/Nhowka/DartToFableBindings). I started handling only the constructors for now and got [this result for the flutter library](https://gist.github.com/Nhowka/4590ddb89d42cce93551697fff8009fd#file-flutterbindings-fs). Function types, the generics...

Yes, we could plug some pre-analysis step to check for changes only start the generation if there is a new or different version package. Maybe we could create a project...

Flutter is [somewhat unique](https://github.com/dart-lang/dartdoc/blob/a535f048b3235baba39a4bd2ffe82648ad208b54/example/README.md#flutter). They generate a dummy pubspec to make it compatible with dartdoc. Maybe you can get some output by creating a dummy empty flutter project that depends...

@bentok, I believe that for typical packages with standard pubspec files, the same surface outputted on their [dartdoc documentation](https://pub.dev/documentation/flutter_secure_storage/latest/flutter_secure_storage/flutter_secure_storage-library.html) on pub.dev should be available to us. Could there be some...

For Dart my main concern was about the methods and fields that exist outside classes, but you are right about being unable to represent the optional arguments if we went...

I like how the `open type` consumer code looks. It could be frictionless if we have some guidance on what should be open in most cases. As for the other...