Skip to content

feat(gnoweb): consolidate built-in playground UI#5565

Open
jeronimoalbi wants to merge 24 commits intognolang:playground2from
jeronimoalbi:playground2-m0
Open

feat(gnoweb): consolidate built-in playground UI#5565
jeronimoalbi wants to merge 24 commits intognolang:playground2from
jeronimoalbi:playground2-m0

Conversation

@jeronimoalbi
Copy link
Copy Markdown
Member

Addresses milestone 0 (M0) from #5549

@jeronimoalbi jeronimoalbi self-assigned this Apr 21, 2026
@github-actions github-actions Bot added 📦 ⛰️ gno.land Issues or PRs gno.land package related 🌍 gnoweb Issues & PRs related to gnoweb and render labels Apr 21, 2026
@Gno2D2
Copy link
Copy Markdown
Collaborator

Gno2D2 commented Apr 21, 2026

🛠 PR Checks Summary

All Automated Checks passed. ✅

Manual Checks (for Reviewers):
  • IGNORE the bot requirements for this PR (force green CI check)
Read More

🤖 This bot helps streamline PR reviews by verifying automated checks and providing guidance for contributors and reviewers.

✅ Automated Checks (for Contributors):

No automated checks match this pull request.

☑️ Contributor Actions:
  1. Fix any issues flagged by automated checks.
  2. Follow the Contributor Checklist to ensure your PR is ready for review.
    • Add new tests, or document why they are unnecessary.
    • Provide clear examples/screenshots, if necessary.
    • Update documentation, if required.
    • Ensure no breaking changes, or include BREAKING CHANGE notes.
    • Link related issues/PRs, where applicable.
☑️ Reviewer Actions:
  1. Complete manual checks for the PR, including the guidelines and additional checks if applicable.
📚 Resources:
Debug
Manual Checks
**IGNORE** the bot requirements for this PR (force green CI check)

If

🟢 Condition met
└── 🟢 On every pull request

Can be checked by

  • Any user with comment edit permission

@jeronimoalbi
Copy link
Copy Markdown
Member Author

jeronimoalbi commented Apr 21, 2026

View Light Dark
Playground playground-light playground-dark
Fork fork-light fork-dark
Eval eval-light eval-dark
Run run-light run-dark

@alexiscolin alexiscolin self-requested a review April 21, 2026 18:22
@alexiscolin
Copy link
Copy Markdown
Member

@jeronimoalbi Thank you for taking care of this. When you finish, can I jump into your PR to make some adjustments?

@alexiscolin alexiscolin self-assigned this Apr 21, 2026
@alexiscolin alexiscolin added the a/ux User experience, product, marketing community, developer experience team label Apr 21, 2026
@jeronimoalbi
Copy link
Copy Markdown
Member Author

@jeronimoalbi Thank you for taking care of this. When you finish, can I jump into your PR to make some adjustments?

@alexiscolin of course 👍

@jeronimoalbi jeronimoalbi marked this pull request as ready for review April 22, 2026 17:35
@jeronimoalbi
Copy link
Copy Markdown
Member Author

@jeronimoalbi Thank you for taking care of this. When you finish, can I jump into your PR to make some adjustments?

@alexiscolin let me know if you think this PR should cover other aspects. The focus was on making the code in playground2 branch consistent and better integrated with Gnoweb. There is room for improvements, but I wanted to keep it simple in case we can address non key improvements in the future.

Feel free to push and improve on this PR 👍

@jeronimoalbi jeronimoalbi requested a review from moul April 22, 2026 17:40
@jeronimoalbi
Copy link
Copy Markdown
Member Author

jeronimoalbi commented Apr 22, 2026

Something that is not quite clear so far is how to deal with the top menu, specially when the Playground is displayed. Right now Playground has no menu because the items didn't make sense within that context.

Also we should add a link to the Playground view somewhere.

@alexiscolin
Copy link
Copy Markdown
Member

alexiscolin commented Apr 23, 2026

Something that is not quite clear so far is how to deal with the top menu, specially when the Playground is displayed. Right now Playground has no menu because the items didn't make sense within that context.

Also we should add a link to the Playground view somewhere.

That's where I would like to make some improvements. This view is not optimal right now in term of UX 👍 I'm also gonna merge some views to it easier to manipulate.

@nemanjantic nemanjantic moved this from Triage to In Review in 🧙‍♂️Gno.land development Apr 23, 2026
Copy link
Copy Markdown
Member

@alexiscolin alexiscolin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pushing this forward Jerónimo. The visual direction is right: dark mode, the header unification across views, the tab typography all land better.

A few inline notes below on small regressions I spotted in the diff. Nothing unfixable.

Three things that aren't in this diff but feel worth raising before we call M0 done, per #5549. Happy to split them as separate PRs on playground2 if you prefer, just want them on the radar:

  1. Nav. The default dev links case in layout_header.go still returns 6 tabs (Content / Source / Actions / Eval / Fork / Run). I know that came from #5421 not from this PR, but since M0 lists nav as a dimension and M1/M2 will absorb Fork and Eval into Source and Actions, does it make sense to drop them from the header already? URLs stay reachable for deep links, we just don't train users on a 6-tab topology we'll undo. We can keep it in mind for the following PRs.

  2. Controllers alignment. controller-playground.ts, controller-eval.ts, and controller-run.ts are factory functions, while every other controller in the codebase extends BaseController. M0 lists this as controller alignment, and M1 will need cross-controller dispatch (Source → Playground) which the factory pattern doesn't expose. You're already editing these files here, so the delta would be small. Do in this PR or next one on playground2?

  3. Dead code after the renderRunContent collapse? Not in the diff but view_run.go:27 still wraps data in runViewParams.Article pointing to renderRunContent, a template that no longer exists right? Harmless today (never rendered), but a trap if anyone re-adds layout/article to realign with the other views.

<div class="c-stack" data-eval-target="history-list">
</div>
<h2 class="b-content-h2">History</h2>
<div class="b-eval-history-list" data-eval-target="history-list" />
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: <div ... /> self-closing syntax isn't valid HTML5 for non-void elements (the / is ignored by the parser). It renders fine here because the </div> on the next line balances it, but the syntax is confusing for readers used to JSX/XHTML.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done 7d65338

<div class="b-eval-result">
<div class="b-eval-result-header">
<span>Result</span>
<h3 class="b-eval-result-title">Result</h3>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: "Result" went from <span> to <h3>, so DOM order now reads h1 → h3 Result → h2 Quick Call → h2 History, which is backwards for screen readers.
WDYT about keeping it as a span (or a panel-title class if we factor the shared panel primitive later)?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done 7d65338

<div class="b-playground-output">
<div class="b-playground-output-header">
<span class="b-playground-output-title">Output</span>
<h3 class="b-playground-output-title">Output</h3>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same thought as on eval: "Output" feels more like a pane label than a section heading. Span rather than <h3>?

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done 7d65338

padding: var(--g-space-1-5);
border: 1px solid var(--s-color-border-default);
border-radius: var(--g-radius-1);
border: 1px solid var(--s-color-border-defaul);
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
border: 1px solid var(--s-color-border-defaul);
border: 1px solid var(--s-color-border-default);

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done 7d65338

Co-authored-by: Alexis Colin <alexis@jaunebleu.co>
@jeronimoalbi
Copy link
Copy Markdown
Member Author

jeronimoalbi commented Apr 23, 2026

Thanks for pushing this forward Jerónimo. The visual direction is right: dark mode, the header unification across views, the tab typography all land better.

A few inline notes below on small regressions I spotted in the diff. Nothing unfixable.

Three things that aren't in this diff but feel worth raising before we call M0 done, per #5549. Happy to split them as separate PRs on playground2 if you prefer, just want them on the radar:

  1. Nav. The default dev links case in layout_header.go still returns 6 tabs (Content / Source / Actions / Eval / Fork / Run). I know that came from feat(gnoweb): built-in playground(2) #5421 not from this PR, but since M0 lists nav as a dimension and M1/M2 will absorb Fork and Eval into Source and Actions, does it make sense to drop them from the header already? URLs stay reachable for deep links, we just don't train users on a 6-tab topology we'll undo. We can keep it in mind for the following PRs.
  2. Controllers alignment. controller-playground.ts, controller-eval.ts, and controller-run.ts are factory functions, while every other controller in the codebase extends BaseController. M0 lists this as controller alignment, and M1 will need cross-controller dispatch (Source → Playground) which the factory pattern doesn't expose. You're already editing these files here, so the delta would be small. Do in this PR or next one on playground2?
  3. Dead code after the renderRunContent collapse? Not in the diff but view_run.go:27 still wraps data in runViewParams.Article pointing to renderRunContent, a template that no longer exists right? Harmless today (never rendered), but a trap if anyone re-adds layout/article to realign with the other views.

I would address these in follow-up PRs if you agree, to make it easier to review. We could link back to your comment from the PRs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

a/ux User experience, product, marketing community, developer experience team 🌍 gnoweb Issues & PRs related to gnoweb and render 📦 ⛰️ gno.land Issues or PRs gno.land package related

Projects

Status: In Progress
Status: In Review

Development

Successfully merging this pull request may close these issues.

4 participants