mirror of
https://github.com/sourcegraph/sourcegraph.git
synced 2026-02-06 19:21:50 +00:00
d2b6ffa2b3
Closes srch-730 This is an initial attempt to improve the web app for small screens. This commit makes the following changes for small screens: - Search home page: - No more search input overflow - History button is rendered on same line as other action buttons (saves some vertical space) - Search results page: - Search input is rendered in the page, not in the header (more space) - Filters sidebar is hidden by default and can be shown via a `Filters` button. - The filters sidebar opens fullscreen and has a close button - The progrss button is smaller due to showing less information - Repository pages: - File sidebar is hidden by default. It can be shown via a new button that is visible in the file headers - The file sidebar opens fullscreen and has a close button - NOTE: Selecting a file currently does not close the file sidebar, navigation happens in the background - Cody sidebar opens fullscreen and has the same close button - General: - Fuzzy finder opens fullscreen and has a larger close button - Tabs don't show keyboard shortcuts I tried to stick to CSS as much as possible but for some things to work I had to change component structures or rendered elements conditionally. Specifically when a component was already using `$isViewportMobile` I usually just rendered elements conditionally. I extended the `Panel` component to have a special 'mobile' mode, since I realized I was doing similar changes to the filters, file tree and cody sidebar. The cody sidebar is a bit of a special case though because it's not even rendered by default. So there are some additional steps required to sync the open state. Screenshots (iPhone SE, which is one of the smaller phones I guess) | Situation | Before | After | |--------|--------|--------| | Search home |  |  | | Search results |  |  | | Filters |  |  | | Repo |  |  | | File sidebar |  |  | | Cody sidebar |  |  | | Repo search |  |  | | Fuzzy finder |  |  | | Rev picker |  |  | Me rambling about the changes: https://github.com/user-attachments/assets/670f7764-0ef2-4f1b-bc33-89a86d4b2274 Note that the commits and commit pages already seem to look fine. The branches, tags and contributors pages are a bit broken due to use of tables and fixed columns. I can look at those separately. ## Test plan Manual testing |
||
|---|---|---|
| .. | ||
| branded | ||
| browser | ||
| build-config | ||
| client-api | ||
| codeintellify | ||
| cody-context-filters-test-dataset | ||
| cody-shared | ||
| cody-ui | ||
| common | ||
| eslint-plugin-wildcard | ||
| extension-api | ||
| extension-api-types | ||
| http-client | ||
| jetbrains | ||
| observability-client | ||
| observability-server | ||
| shared | ||
| storybook | ||
| template-parser | ||
| testing | ||
| vscode | ||
| web | ||
| web-sveltekit | ||
| wildcard | ||
| BUILD.bazel | ||
| README.md | ||
Frontend packages
List
- web: The web application deployed to http://sourcegraph.com/
- browser: The Sourcegraph browser extension adds tooltips to code on different code hosts.
- vscode: The Sourcegraph VS Code extension.
- extension-api: The Sourcegraph extension API types for the Sourcegraph extensions. Published as
sourcegraph. - extension-api-types: The Sourcegraph extension API types for client applications that embed Sourcegraph extensions and need to communicate with them. Published as
@sourcegraph/extension-api-types. - sandboxes: All demos-mvp (minimum viable product) for the Sourcegraph web application.
- shared: Contains common TypeScript/React/SCSS client code shared between the browser extension and the web app. Everything in this package is code-host agnostic.
- branded: Contains React components and implements the visual design language we use across our web app and e.g. in the options menu of the browser extension. Over time, components from
sharedandbrandedpackages should be moved into thewildcardpackage. - wildcard: Package that encapsulates storybook configuration and contains our Wildcard design system components. If we're using a component in two or more different areas (e.g.
web-appandbrowser-extension) then it should live in thewildcardpackage. Otherwise the components should be better colocated with the code where they're actually used. - search: Search-related code that may be shared between all clients, both branded (e.g. web, VS Code extension) and unbranded (e.g. browser extension)
- storybook: Storybook configuration.
Further migration plan
-
Fix circular dependency in TS project-references graph wildcard package should not rely on web and probably shared, branded too. Ideally it should be an independent self-contained package.
-
Decide on package naming and update existing package names. Especially it should be done for a shared package because we have multiple
sharedfolders inside of other packages. It's hard to understand from where dependency is coming from and it's not possible to refactor import paths using find-and-replace. -
Investigate if we can painlessly switch to
npmworkspaces. -
Content of packages shared and branded should be moved to wildcard and refactored using the latest FE rules and conventions. Having different packages clearly communicates the migration plan. Developers first should look for components in the wildcard package and then fall-back to legacy packages if wildcard doesn't have the solution to their problem yet.
-
shared contains utility functions, types, polyfills, etc which is not a part of the Wildcard component library. These modules should be moved into utils package and other new packages: e.g. api for GraphQL client and type generators, etc.
-
Packages should use package name (e.g.
@sourcegraph/wildcard) for imports instead of the relative paths (e.g.../../../../wildcard/src/components/Markdown) to avoid long relative-paths and make dependency graph between packages clear. (Typescript will warn if packages have circular dependencies). It's easy to refactor such isolated packages, extract functionality into new ones, or even into new repositories.