-
-
Notifications
You must be signed in to change notification settings - Fork 182
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
Documentation Enhancements Conversation #118
Comments
Hi! I love the idea. It'd probably be a better idea to make examples in the dartdoc of each individual hooks, extract these code snippets, and upload them to github gists so that we can run them on dartpad That should be feasible using some of the more advanced features of dartdoc like macro. That's how Flutter doc works atm What do you think? |
I think it's good to have each example separate to make things more interactive. At the moment DartPad only supports imports from the dart and flutter packages; so even if we could pull examples in from gists, we couldn't run it without copying the source of flutter_hooks above the example. Unless there's another way? |
It should be feasible to fork the sources of the library Like take all the sources, and append them to the example gist |
More specifically, we can try merging all the sources of flutter_hooks in a single file, and add it implicitly to our example gists That should be good enough until there's a proper way to add pubspec dependencies |
Then we can embed the gists to the generated dart docs as specified here: Let me know if you have concerns. |
That's epic, good job! It'd be great to add this to the CI and try to run the existing tests on the generated file. Also, if I remember correctly it's possible to have multiple files on dartpad. I think there's also some situations where this file can be hidden. I think naming it |
If you have the script, I can try to get the CI part done 😊 |
Here's the script to generate a single-file library. Multiple-file DartPad isn't going well I'm going to attempt to use the hard-coded file-names their documentation use like |
The layout codelab has examples of gists with multiple files: https://gist.github.com/legalcodes/6b00f558718e9f23de5c61503aa1bfe4 So it should be feasible. |
I tried every permutation, Check it out! All imports need to be in the same file and the only files that may import are main and test. |
Nice! That's a lot better! I'll explore tomorrow if we can plug this to the dartdoc, such that we'd have: /// Some documentation
///
/// {@macro whatever}
/// ```dart
/// class Example extends HookWidget {
/// @override
/// Widget build(BuildContext context) {
/// final myAnimation = useAnimationController(...)
/// useAnimation(myAnimation);
/// return Text('$myAnimation');
/// }
/// }
/// ```
/// {@endmacro}
AnimationController useAnimationController(...) {...} |
I've given this some thought: Converting Code Blocks to DartPad seems very close to what we want, but I haven't considered how to access the flutter_hooks file in that scenario. We may need something like @tool. I'm unsure. What we really need is for DartPad to be more dynamic. We want a hard-coded |
I tried to implement something similar for Hive and I ended up forking |
Ah, forgot to answer~ @leisim, could you explain a bit more in what you had to do? 😄 |
Hello, I love hooks and I love Flutter. I want to make hooks the de-facto way we write widgets in Flutter, so I want to lower the barrier to entry with snazzy documentation.
Here are some problems I want to solve:
Here's what I have so far
I have written an example for useAnimationController and hosted the example project using Github Pages. Try it out! https://leecommamichael.github.io/flutter_hooks/#/
If we move in this direction, we can add a build-step in the travis.yml to update the documentation. We can embed the app (which is hosted by GitHub Pages) in our generated Dart documentation or the Readme. I know that dartdoc can embed HTML in iframes, which is perfect. I'm unsure if Markdown can do the same for our README. To make give context when viewing docs, I can have the navigator present the example for the hook the user is looking at in the dart doc page.
It'd be ideal to use something like https://dartpad.dartlang.org/embed-flutter.html, but we'd have to implement it ourselves in order to pull the flutter_hooks package in.
What does everyone think? Do you also find this valuable? Is this a good approach, should I continue?
The text was updated successfully, but these errors were encountered: