logan
23f5a0c53a
The header indicator is a disclosure anchored to a bar 3.25em tall on a screen 439 CSS px tall, and it was reported as unreadable behind other UI. Background work is the one thing a phone should not make you open something to see, and #57 deletes the bar it hangs from and is blocked on it having somewhere else to live. Below 600px the indicator stands down and <job-band> takes over. It is the existing job-panel at `kinds="*"`, so pause, cancel, Details and the log come along, and so does applyJobControl. **It is in the layout, not over it**, and that was measured rather than assumed. The first version put the panel in notification-host's fixed band: it renders correctly, sits on top and stays inside the viewport, and is unusable -- at 424x439 a compact panel showing two jobs is ~216px of a 439px screen, drawn over the content and swallowing every tap under it. Four e2e specs caught it, and none of them was about jobs: two phone-shell journeys and the header's action menu, all failing on clicks the band was intercepting. As a grid row above the main panel it pushes instead, which is #24's one sentence deciding a layout question -- a band that hides the app to say the app is busy has traded the popover's fault for a worse one. It renders nothing above 600px, from matchMedia rather than a media query, because that decides whether the element exists: Settings already holds four job-panels and a fifth answering for every kind is bottom-nav's "resolved to 2 elements" trap again. index.css keeps it display:none off the phone for a second reason -- an in-flow grid child with no named area is auto-placed into one of the shell's rows, which is what the skip link is absolutely positioned to avoid. top-bar-fit's 390px case asserted the indicator was up, so that it could not pass by measuring the idle case under another name. At phone width it is now deliberately away, so the assertion takes the other branch of the same rule -- the indicator is hidden, the band has the row, and the bar still has nothing hanging out of it -- rather than the width being quietly dropped from the list. The report's own symptom is deliberately not asserted anywhere: it did not reproduce in this tier. Measured at 424x439 the popover was neither clipped nor covered, so a spec claiming a stacking fix would be asserting something that was never true here. The spec says so. Closes #62
YellowJacket Frontend
This directory contains the frontend for YellowJacket.
Dependencies
There are a couple of tools that are required to build and use the frontend.
vitefor- transpiling typescript
- bundling the final "package" that is useb by the webview
- running a dev server with hot-reloading
- configured with the
vite.config.tsfile in this directory
pnpmfor managing frontend dependency packages
There are a handful of dependency packages that we use directly in the frontend.
picocssfor basic CSS while developinglitfor a simple but powerful wrapper around Web Components
Lastly, there are some dependencies that only benefit development
tsservercomes bundled with vscode and can be used as an LSP with other editors usingtypescript-language-server- Used for autocomplete, syntax highlighting, etc.
- This can be configured with the
tsconfig.jsonfile in the root of the project- NOTE: your configuration should align with the
viteconfig so you get in-editor feedback that aligns with how the build will be done.
- NOTE: your configuration should align with the
Development
Ideally, you would use the frontend in the wails app as the frontend depends on the Go bindings generated by Wails.
You can do this by running wails dev in the root of the YellowJacket repo.
If you want to run the frontend standalone, make sure the Wails go bindings have been generated with wails generate modules.
Then, you can run pnpm dev to run the vite dev server.
For more information on what commands are available, refer to package.json.
Code
Web Components
Our frontend is based off of Web Components, a standard that provides native browser encapsulation of components that can include HTML, CSS and Javascript all together.
Instead of writing these components manually in Javascript, we utilize lit as a wrapper library.
Typescript
To better integrate with our tooling and to provide a better developer experience with strong typing, we have written all functional frontend code in Typescript. Vite serves as our Typescript transpiler.
Important Files and Directories
NOTE: most of these directories have aliases defined in tsconfig.json and vite.config.ts so that we may refer to them by shorthand when importing.
index.htmlandindex.jsis the entrypoint for the frontend. The first page that loads.wailsjs/goGo code bindings generated by wails reside herewailsjs/runtimethe Wails runtime code needed to use Wails featuressrcall app code resides heresrc/assetsstatic assets like fonts, images and iconssrc/componentslit components that are used to compose the applicationsrc/pagespages that serve as other entrypoints for the application that can be navigated to