Page MenuHomePhabricator

Clean up the Vite sandbox
Closed, ResolvedPublic

Description

One of the ways developers can work on components locally is within the sandbox provided by Vite. This simple local dev environment is fast and no-frills, meaning component development can be done quickly and in an isolated environment (i.e. there are no styles potentially polluting the components, like in VitePress).

However, the sandbox could use some work:

  • It's a single file containing all components, which is becoming unwieldy and disorganized
  • It's being used to demo components in MediaWiki in the VueTest extension (it was manually copied there, but we might automate this in the future), which means the only thing being tested in a MediaWiki context is what we put in the Sandbox. We may want to consider what kinds of test cases should be included in the Sandbox to lead to adequate testing in MediaWiki.
  • In general, there are no standards as far as whether a component must be included in the Sandbox, how it should be included, and how many examples should be included

Acceptance criteria

  • Decide on and document standards for the sandbox during component development. These should be as lightweight as possible, and adding a full suite of test cases (if that's what we want) could happen in a subsequent task done by another developer, to ease the burden on the main developer
  • Clean up and organize the sandbox according to those standards:
    • Each demo gets its own wrapper component: <ButtonDemo />, <TabsDemo />, etc.
    • Each demo component contains the simple, minimum demonstration of what a component does; more exhaustive demonstrations can live on the docs pages
    • The sandbox page displays all the component demos in one long view; nothing is hidden inside of tabs, etc;
    • Only components that have been included in a Codex release are included here

Future work: automate pulling the sandbox contents into Special:VueTest so it's kept up to date

Screenshot of the new demo layout:

Screen Shot 2022-08-05 at 1.00.27 PM.png (2×2 px, 797 KB)

Event Timeline

egardner subscribed.

I'm willing to take a first stab at this - I've also been thinking about ways to improve the VueTest MW extension; hopefully there will be some overlap here.

I'd like to propose making the following changes to the Sandbox (available when developers run npm run dev in the Codex repo).

  • Each demo gets its own wrapper component: <ButtonDemo />, <TabsDemo />, etc.
  • Each demo component contains the simple, minimum demonstration of what a component does; more exhaustive demonstrations can live on the docs pages
  • The sandbox page displays all the component demos in one long view; nothing is hidden inside of tabs, etc;
  • Only components that have been included in a Codex release are included here

My reasoning for this is that I'd like to re-use the sandbox demo components inside of VueTest, so we can do basic component testing in a MediaWiki environment. The VueTest extension will need to define its own top-level "sandbox" page to display all the demos, but ideally the demo components themselves could be compiled and distributed somehow along with the rest of Codex – as long as this can be done in a way so that they are not loaded at runtime by normal uses of @wikimedia/codex. (@Catrope maybe you have some ideas here.) This way we can write them in TS using <script setup> for convenience, but then they can be compiled down to regular JS for use inside of MW.

I will update the acceptance criteria for this ticket if there is a consensus around this approach.

egardner changed the task status from Open to In Progress.Aug 3 2022, 6:12 PM

Change 820178 had a related patch set uploaded (by Eric Gardner; author: Eric Gardner):

[design/codex@main] [WIP] Re-organize and improve component sandbox page

https://gerrit.wikimedia.org/r/820178

@egardner that all sounds good to me! I'd also suggest that we put components in alphabetical order, and that we add in some visual separation between them (maybe a horizontal rule, some padding, and a heading with the component name?) to make the page easier to scan.

@egardner that all sounds good to me! I'd also suggest that we put components in alphabetical order, and that we add in some visual separation between them (maybe a horizontal rule, some padding, and a heading with the component name?) to make the page easier to scan.

Sounds good. I was also thinking about a sidebar to allow for quickly jumping to the anchor link for a given component's section.

This all sounds good to me, and I support the idea of including a sidebar, otherwise navigating to a particular component will be difficult.

  • Only components that have been included in a Codex release are included here

If that's the case, we should come up with a place (maybe a separate sandbox?) where experimental components (the ones not ready for release) can go, since part of the the point of this task is to make the sandbox a lighter-weight alternative to the demos for initial component patches.

My reasoning for this is that I'd like to re-use the sandbox demo components inside of VueTest, so we can do basic component testing in a MediaWiki environment. The VueTest extension will need to define its own top-level "sandbox" page to display all the demos, but ideally the demo components themselves could be compiled and distributed somehow along with the rest of Codex – as long as this can be done in a way so that they are not loaded at runtime by normal uses of @wikimedia/codex. (@Catrope maybe you have some ideas here.) This way we can write them in TS using <script setup> for convenience, but then they can be compiled down to regular JS for use inside of MW.

I think we could include the built sandbox as an additional file in the main Codex NPM package. Configuring Vite for that will be a little bit annoying, but probably doable. Unlike codex-search I would like to avoid making this yet another NPM package, because it's just demos for testing.

As for how to use it in MW/VueTest, I think the cleanest way would be to download that file from NPM and commit it in the VueTest extension. Alternatively, we could add the sandbox file to the list of files that is downloaded from NPM in resources/lib/foreign-resources.yaml (in MW core), so that it ends up in the resources/lib/codex/ directory, and then VueTest would use it from there. Then we wouldn't have to separately update VueTest every time there's a Codex release, but we'd also have an extraneous file in MW core for the benefit of just one test extension.

egardner triaged this task as Medium priority.Aug 9 2022, 12:24 AM

Change 820178 merged by jenkins-bot:

[design/codex@main] Re-organize and improve component sandbox page

https://gerrit.wikimedia.org/r/820178

egardner updated the task description. (Show Details)

Change 823725 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[mediawiki/core@master] Update Codex from v0.1.0-alpha.9 to v0.1.0-alpha.10

https://gerrit.wikimedia.org/r/823725

Change 823725 merged by jenkins-bot:

[mediawiki/core@master] Update Codex from v0.1.0-alpha.9 to v0.1.0-alpha.10

https://gerrit.wikimedia.org/r/823725