Bryan
edd8345658
Fixes #452 When the empty state is rendered with a non-textual element (which it turns out all our current empty states are, because they have a `<button />` component as a call to action), this noisy error log was showing up in the `console`: ``` Warning: validateDOMNesting(...): <div> cannot appear as a descendant of <p>. at div at div at p at Typography (webpack-internal:///./node_modules/@material-ui/core/esm/Typography/Typography.js:166:28) at WithStyles (webpack-internal:///./node_modules/@material-ui/styles/esm/withStyles/withStyles.js:64:31) at div at StyledComponent (webpack-internal:///./node_modules/@material-ui/styles/esm/styled/styled.js:95:28) at EmptyState (webpack-internal:///./src/components/EmptyState/index.tsx:47:25) ... at ProjectsPage (webpack-internal:///./src/pages/projects/index.tsx:37:18) at Routes (webpack-internal:///./node_modules/react-router/index.js:275:5) at ThemeProvider (webpack-internal:///./node_modules/@material-ui/styles/esm/ThemeProvider/ThemeProvider.js:44:24) at UserProvider (webpack-internal:///./src/contexts/UserContext.tsx:100:55) at SWRConfig$1 (webpack-internal:///./node_modules/swr/dist/index.esm.js:501:23) at Router (webpack-internal:///./node_modules/react-router/index.js:209:15) at BrowserRouter (webpack-internal:///./node_modules/react-router-dom/index.js:118:5) at App ``` The issue was that the `description` prop could either be a `string` or an actual `React` component, but was always rendered as a child of a `<Typography />` component. The `<Typography>` component internally renders as a `<p>`, which is not valid to nest `<div>`s inside. The fix is to not nest inside a `<Typography />` block, but an actual `<div />`.
Coder v2
This repository contains source code for Coder V2. Additional documentation:
Directory Structure
.github/: Settings for Dependabot for updating dependencies and build/deploy pipelines with GitHub Actions.semantic.yaml: Configuration for semantic pull requests
examples: Example terraform project templates.site: Front-end UI code.
Development
Pre-requisites
gitgoversion 1.17, with theGOPATHenvironment variable setnodeyarn
Cloning
git clone https://github.com/coder/codercd coder
Building
make buildmake install
The coder CLI binary will now be available at $GOPATH/bin/coder
Running
After building, the binaries will be available at:
dist/coder_{os}_{arch}/coder
For the purpose of these steps, an OS of linux and an arch of amd64 is assumed.
To manually run the server and go through first-time set up, run the following commands in separate terminals:
dist/coder_linux_amd64/coder daemon<-- starts the Coder server on port 3000dist/coder_linux_amd64/coder login http://localhost:3000<-- runs through first-time setup, creating a user and org
You'll now be able to login and access the server.
To create a project, run:
dist/coder_linux_amd64/coder projects create -d /path/to/project
Development
./develop.sh
The develop.sh script does three things:
- runs
coder daemonlocally on port3000 - runs
webpack-dev-serveron port8080 - sets up an initial user and organization
This is the recommend flow for working on the front-end, as hot-reload is set up as part of the webpack config.
Front-End Plan
For the front-end team, we're planning on 2 phases to the 'v2' work:
Phase 1
Phase 1 is the 'new-wine-in-an-old-bottle' approach - we want to preserve the look and feel (UX) of v1, while testing and validating the market fit of our new v2 provisioner model. This means that we'll preserve Material UI and re-use components from v1 (porting them over to the v2 codebase).
Phase 2
Phase 2 is the 'new-wine-in-a-new-bottle' - which we can do once we've successfully packaged the new wine in the old bottle.
In other words, once we've validated that the new strategy fits and is desirable for our customers, we'd like to build a new, v2-native UI (leveraging designers on the team to build a first-class experience around the new provisioner model).