Dartpad-Preview_ hide filetree, tabs and breadcrumbs in embed mode

[LeonMollNetlight]

• Adds url params to hide/collapse or show panels (see below for list)
• hide file navs in embed mode on default

Before:

After:

Excerpt from the README

Panel configuration

The URL sets each panel's initial state, but these are interpreted as hints and there are exceptions.
In the app, users can then expand or collapse panels.

Use comma-separated panel names, each prefixed with + or -:

?embed=true&panels=+tabs,-file_tree,-preview

+ expands a panel. - collapses it in standalone mode and hides it in embeds,
except that tabs stay visible in standalone mode and can only be hidden in
embeds. bottom_panels remain accessible as described below.

Panel	Group	Standalone default	Embed default
bottom_panels	Console and Problems	Expanded	Collapsed
preview	Preview / output	Expanded	Expanded
tabs	Editor tabs and breadcrumbs	Expanded	Hidden, unless multiple distinct file values are supplied
file_tree	File tree	Expanded	Hidden
status_bar	Status footer	Expanded	Hidden
app_bar	App header	Expanded	Hidden

In embeds, -bottom_panels collapses instead of hiding so Console and Problems
remain accessible.

Fixes #3973

[github-actions]

PR Health

Coverage ✔️

File	Coverage

This check for test coverage is informational (issues shown here will not fail the PR).

This check can be disabled by tagging the PR with skip-coverage-check.

License Headers ✔️

// Copyright (c) 2026, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

Unrelated files missing license headers

Files
pkgs/dart_services/lib/src/context.dart
pkgs/dartpad_preview/examples/counter/lib/main.dart
pkgs/dartpad_preview/examples/fibonacci/bin/main.dart
pkgs/dartpad_preview/examples/snippet_dart/bin/main.dart
pkgs/dartpad_preview/examples/sunflower/lib/main.dart
pkgs/samples/lib/brick_breaker.dart
pkgs/samples/lib/fibonacci.dart
pkgs/samples/lib/hello_world.dart
pkgs/samples/lib/main.dart
pkgs/samples/lib/sunflower.dart

This check can be disabled by tagging the PR with skip-license-check.

Breaking changes ✔️

Package	Change	Current Version	New Version	Needed Version	Looking good?

This check can be disabled by tagging the PR with skip-breaking-check.

Unused Dependencies ✔️

Package	Status
None	No packages found to check.

For details on how to fix these, see dependency_validator.

This check can be disabled by tagging the PR with skip-unused-dependencies-check.

API leaks ✔️

The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.

Package	Leaked API symbol	Leaking sources

This check can be disabled by tagging the PR with skip-leaking-check.

Changelog Entry ✔️

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

This check can be disabled by tagging the PR with skip-changelog-check (for example, for non-user-visible changes when the package version is already at -wip).

[jonasfj]

we need to call it something else.

snake_case I would think for query string options.

probably we would rather that it's something like &hide=file-tree,editor-tabs,preview a comma separated list (or &hide=file-tree&hide=editor-tabs&hide=preview which is probably interpreted as the same).

I think breadcrumbs and editor-tabs belong as one option.

We can also choose to not have an option here. and only derive behavior from embed.

But I think we should consider something generic. Or perhaps we just in the future may a different way of embedding that doesn't have any of this legacy behavior.

But I think we should not make a public option called hideFileNavigation because that becomes a commitment.

[LeonMollNetlight]

But will there be use cases for hiding the preview?

I see the use case for hiding the filetree, but not the editortabs if someone wants to show a simple embed with 2 files without wasting space for the file tree.

But I would be against having preview as an option here because I don't see a use case for hiding it.
And then these flags could just be "on" by default and use show? So the default url would just be embed without any hides. And if I want to show the tabs I do:

/?embed=true&show=editor-tabs

Because if we do all the flags, then our defaults would be sometimes true/show and sometimes false/hide. For the current embed for example show for preview but hide for filetree and editortabs. And having the same default for every element makes it easier to understand/configure.

[jonasfj]

maybe what we want is a generic ?panels=+mypanel,-otherpanel with

• + meaning show mypanel, and,
• - meaning hide otherpanel.

And we document that we interpret these as hints that we don't promise we'll honor.
And that for panels no specified we'll infer, a default from the context.

I could see the case that if multiple &file=foo.dart&file=bar.dart are given, then probably you want tabs to be displayed.

I can see use cases for hiding preview: If I want to show code that has LSP + go-to definition. Maybe, I want to demo a lint 🤣 (Like this page could totally just have two dart pads: https://dart.dev/tools/linter-rules/always_declare_return_types)

[jonasfj]

We can debate that maybe panels=-foo means:

• hide foo in embed mode
• collapse foo in non-embed mode.

And perhaps for console and problems, we don't even support hide in embed-mode.

---

Like maybe panels is a way to say:

• + this panel is important,
• - this panel is unimportant.

And we interpret that is meaning show/hide/collapse depending on what panel and mode we are in.

[jonasfj]

panels we have:

• problems
• console (we probably want to support both, because +console means switch to console be default)
• preview
• tabs
• editor (not sure, this something users can collapse)
• files / filetree / explorer (not sure what we should call it)
• statusbar / status (not sure what to call it)
• appbar / header (not sure what to call it)

[LeonMollNetlight]

Sounds cool! I like the important and unimportant part.
So in embed mode its hide, in non embed its collapse.

And fair point, I see the non preview use case now.

Maybe we can group problems and console under bottomPanels?
Editor is currently not really hidable/collapsible. Only in the mobile view where we show editor OR preview. So I would be for not giving that option

I would go for filetree

statusbar is a term that at least I know and I think in VS Code the thing is also called status bar.

TLDR, this would be my suggestion:

• bottomPanels
• preview
• tabs (including breadcrumbs)
• fileTree
• statusBar
• appBar