134c32589a
Fixes a bug where the dashboard would scroll you down from the top of the page on load if your window was too short too see both the selected flag and the selected project. This solves it by immediately scrolling to the top of the page after scrolling your selected element into view. Because this hook only runs on page load, it shouldn't be safe. (At least I couldn't make this misbehave with manual testing). It also changes the list scroll behavior to scroll your selected item to the top of the list instead of to the bottom (effectively). During testing, that seems like a better solution to me. ## Background (or why do we auto-scroll here?) The dashboard's flag and projects panels stores your last selection, so that when you return to the page you'll be shown what you were looking at last. This is especially useful if you have a lot of flags but you're focusing on one in particular. However, if you **do** have a lot of flags, then it's also quite likely that your selection will be "below the fold" of the panel, and you won't see your selected flag/project immediately in the list (without scrolling). It seemed like a nice UI affordance to automatically bring your selected item into view (especially because without it, there's no way to see what flag/project) you're looking at, so I added the [`scrollIntoView`](https://developer.mozilla.org/en-US/docs/Web/API/Element/scrollIntoView) hook. What I didn't realize, however, is that it scrolls all scrollable ancestor containers, which means that if your screen is too short, it'll scroll you down the page. From my reading of the docs and some local testing, I don't think there is a way to limit the scrolling to only the nearest ancestor, so the easiest way to ensure that we're always at the top seemed to be to just scroll to the immediately after. |
||
|---|---|---|
| .. | ||
| .yarn/releases | ||
| cypress | ||
| public | ||
| scripts | ||
| src | ||
| .editorconfig | ||
| .gitignore | ||
| .npmignore | ||
| .nvmrc | ||
| .yarnrc.yml | ||
| check-imports.rc | ||
| cypress.config.ts | ||
| cypress.d.ts | ||
| index.html | ||
| index.js | ||
| orval.config.js | ||
| package.json | ||
| README.md | ||
| tsconfig.json | ||
| tsconfig.node.json | ||
| vercel.json | ||
| vite.config.mts | ||
| yarn.lock | ||
frontend
This directory contains the Unleash Admin UI frontend app.
Run with a local instance of the unleash-api
Refer to the Contributing to Unleash guide for instructions. The frontend dev server runs (in port 3000) simultaneously with the backend dev server (in port 4242):
yarn install
yarn dev
Run with a sandbox instance of the Unleash API
Alternatively, instead of running unleash-api on localhost, you can use a remote instance:
cd ./frontend
yarn install
yarn run start:sandbox
Running end-to-end tests
We have a set of Cypress tests that run on the build before a PR can be merged so it's important that you check these yourself before submitting a PR. On the server the tests will run against the deployed Heroku app so this is what you probably want to test against:
yarn run start:sandbox
In a different shell, you can run the tests themselves:
yarn run e2e:heroku
If you need to test against patches against a local server instance, you'll need to run that, and then run the end to end tests using:
yarn run e2e
You may also need to test that a feature works against the enterprise version of unleash. Assuming the Heroku instance is still running, this can be done by:
yarn run start:enterprise
yarn run e2e
Generating the OpenAPI client
The frontend uses an OpenAPI client generated from the backend's OpenAPI spec. Whenever there are changes to the backend API, the client should be regenerated:
For now we only use generated types (src/openapi/models). We will use methods (src/openapi/apis) for new features soon.
yarn gen:api
rm -rf src/openapi/apis
clean up src/openapi/index.ts imports, only keep first line export * from './models';
This script assumes that you have a running instance of the enterprise backend at http://localhost:4242.
The new OpenAPI client will be generated from the runtime schema of this instance.
The target URL can be changed by setting the UNLEASH_OPENAPI_URL env var.
Analyzing bundle size
npx vite-bundle-visualizer in the root of the frontend directory