riverpod
riverpod copied to clipboard
rrousselGit
Add ContainerNode and RiverpodNode to devtool
This PR adds support for Flutter DevTools by improving the already present file devtool.dart.
With the changes present here we can more easily get the data needed to present the provider state on Flutter DevTools.
For more information check the discussion here.
The UI that these changes enable is the following:
https://user-images.githubusercontent.com/11666470/174911002-a28792d1-ebca-4c7c-b56e-b88002afdfea.mp4
Soon I will open a PR on devtools with the addition of RiverpodScreen.
I haven't forgotten about this. I'll continue the work on my own during August.
I haven't forgotten about this. I'll continue the work on my own during August.
cool, so you mean you'll continue this work? I can still work on it if you want, I was just waiting for you comments.
Let me know if you need my help.
Cheers!
It'd be great if you could add tests on the devtool PR (not this one, the flutter/devtool repo)
It'd be great if you could add tests on the devtool PR (not this one, the flutter/devtool repo)
For sure! I was just waiting to have this API ready to go. I'll add the tests this week.
Don't worry about this api. I don't mind much what it looks like, since it's not public.
What matters is that everything is tested
@rrousselGit this PR should be ready to be merged, we need to merge it first and create a release since devtools depends on this.
Don't worry about this.
For reference, I don't plan on merging this until the devtool PR is ready to merge. These two PRs are intertined. A problem in one would require a change in the other, so they likely need to be merged at the same time.
This is looking great!
A small note about the sidebar listing providers:
-
I believe that if the provider specifies a name, showing its type is redundant. Especially since we see its type once we select the provider (in the title of the right part)
-
I think it'd be great if providers coming from a
familycould list the argument
More specifically, I could see the rendering of family involve two bits.
Assuming we have:
final myProvider = Provider.family<String, int>((ref, id) => 'Hello $id');
...
ref.watch(myProvider(42));
Then I think the rendering could be:
Containers. |. Exposed value
----------------------------------------
myProvider(42) | family arg:
| 42
|. --------
|. exposed value:
|. 'Hello 42'
Also, for the sake of readability, I think that if there's only one root ProviderContainer, we don't need to show it in the list. We could show the root provider directly.
This would remove one level of indentation on the sidebar
If there are multiple roots, we'd need to keep the rendering as it is. But that's fairly rare I think
really great insights! I'll work on them! They should be easy to implement, I'll work on an UI and share with you soon.
https://user-images.githubusercontent.com/11666470/184650168-4e08a184-e7c5-4fda-9c7c-4276ccd73cd1.mp4
I've made some modifications, WDYT?
What I've changed:
1 - Don't show the container label if there is only one container.
2 - Changed the providers list header to show Providers if there is only one container, otherwise it shows Containers.
3 - Changed how the provider name is rendered, now if the provider is a family provider it also show the argument. Another changes was to remove the type if the provider is named.
4 - Also show the selected provider family argument on the right panel, only if there is one.
Nice! That looks great!
Quick note, what is that "StringValue"? Is it a custom class you made as an example? Or is that the object vm_service gives you?
If that's the latter, I'd expect to see the raw string directly.
Also, we'd need to make sure that there's a text wrap if the family arg toString is too long :)
Acutally, the video showcases that. Ignore me!
That's awesome, nice work!
About the family not being editable:
They are, since I'm using the same viewer as the state. I just tested here and you can just edit a value if it is not final 😞.
I was looking at the instance_viewer that you've made for provider (which is the same that I'm using) and there is no option to disable editing. I could add a flag to the InstanceViewer widget like disableEditing, which defaults to false, this way we won't touch other provider implementations.
WDYT?
And about text wrap:
just added a way to wrap if there is no room for the name.
Sorry I used the wrong word. Rather than text wrap, I think clipping it is better. As in doing myVeryLongProvid...
The sidebar can be expanded anyway, and the provider can be selected to see it in full. I think it's more important to see the full list
Especcially considering objects could override toString and end-up with a very long provider name.
I was looking at the instance_viewer that you've made for provider (which is the same that I'm using) and there is no option to disable editing. I could add a flag to the
InstanceViewerwidget likedisableEditing, which defaults to false, this way we won't touch otherproviderimplementations.WDYT?
SGTM
Epic
A nit point would be to rename 'container" into providerContainer to be more specific. But otherwise LGTM
Epic
A nit point would be to rename 'container" into providerContainer to be more specific. But otherwise LGTM
You mean written like ProviderContainer, just like the class?
And what about the header? Should we keep Containers or change to ProviderContainers ?
You mean written like ProviderContainer, just like the class?
Yes
And what about the header? Should we keep Containers or change to ProviderContainers ?
The header too.
done https://github.com/flutter/devtools/pull/4210/commits/392f6b971b21061f61c9f013309bffebb279ffd1, let me know if you think anything can be improved.
@adsonpleal do you have a social media or a name that I could share?
I'd like you publicly thank you for your work. 😊
I'm one of those weird ones that don't use social media haha. I have a linkedin profile, though. I think you could use it hehe.