This provides a comprehensive webapp interface for LAION's Open Assistant project. Initially it will support:

1. User registration using either Discord or Email.
2. Adding responses to incomplete Open Assistant tasks.
3. Rating or Ranking responses to Open Assistant tasks.
4. Viewing an activity leaderboard.
5. Tracking community wide updates.

This interface compliments the Discord bot and will give access to the same underlying tasks.

This website is built using:

1. npm: The node package manager for building.
2. React: The core frontend framework.
3. Next.js: A React scaffolding framework to streamline development.
4. Prisma: An ORM to interact with a web specific Postgres database.
5. NextAuth.js: A user authentication framework to ensure we handle accounts with best practices.
6. TailwindCSS: A general purpose framework for styling any component.
7. Chakra-UI: A wide collection of pre-built UI components that generally look pretty good.

To contribute to the website, make sure you have the following setup and installed:

1. Node 16: if you are on windows, you can download node from their website, if you are on linux, use NVM (Once installed, run nvm use 16)
2. Docker: We use docker to simplify running dependent services.

If you're doing active development we suggest the following workflow:

1. Open the terminal, navigate to the project root.
2. Run docker compose --profile frontend-dev up --build --attach-dependencies. You can optionally include -d to detach and later track the logs if desired.
   • If you want to work on the chat api, you need to run the inference profile as well. Your new command would look like: docker compose --profile frontend-dev --profile inference up --build --attach-dependencies
   • See FAQ if you face any docker problems.
   • Leave this running in the background and continue:
3. Open another terminal tab, navigate to ${OPEN_ASSISTANT_ROOT/website.
4. Run npm ci
5. Run npx prisma db push (This is also needed when you restart the docker stack from scratch).
6. Run npm run dev. Now the website is up and running locally at http://localhost:3000.
7. To create an account, login via the user using email authentication and navigate to http://localhost:1080. Check the email listed and click the log in link. You're now logged in and authenticated.

   Note: when running on MacOS with an M1 chip you have to use: DB_PLATFORM=linux/x86_64 docker compose ...

You can use the debug credentials provider to log in without fancy emails or OAuth.

1. This feature is automatically on in development mode, i.e. when you run npm run dev. In case you want to do the same with a production build (for example, the docker image), then run the website with environment variable DEBUG_LOGIN=true.
2. Use the Login button in the top right to go to the login page.
3. You should see a section for debug credentials. Enter any username you wish, you will be logged in as that user.

Create a docker-compose.override.yml in the root of the repo, and add the following to it

services:
  inference-server:
    environment:
      # fill out these variables, you would need to create an app from the corresponding provider(s)
      # you can fill only one of them if you want to
      AUTH_DISCORD_CLIENT_ID:
      AUTH_DISCORD_CLIENT_SECRET:

      AUTH_GITHUB_CLIENT_ID:
      AUTH_GITHUB_CLIENT_SECRET:

And now when you start all containers, the possibility to login to inference through these providers will be available.

To develop components using Storybook run npm run storybook. Then navigate to in your browser to http://localhost:6006.

To create a new story create a file named [componentName].stories.tsx. An example how such a story could look like, see Header.stories.tsx.

All react code is under src/ with a few sub directories:

1. pages/: All pages a user could navigate too and API URLs which are under pages/api/.
2. components/: All re-usable React components. If something gets used twice we should create a component and put it here.
3. lib/: A generic place to store library files that are used anywhere. This doesn't have much structure yet.

NOTE: styles/ can be ignored for now.

All database configurations are stored in prisma/schema.prisma.

All static images, fonts, svgs, etc are stored in public/.

We're not really using CSS styles. styles/ can be ignored.

Cypress is used for end-to-end (e2e) and component testing and is configured in ./cypress.config.ts. The ./cypress folder is used for supporting configuration files etc.

• Store e2e tests in the ./cypress/e2e folder.
• Store component tests adjacent to the component being tested. If you want to write a test for ./src/components/Layout.tsx then store the test file at ./src/components/Layout.cy.tsx.

A few npm scripts are available for convenience:

• npm run cypress: Useful for development, it opens Cypress and allows you to explore, run and debug tests. It assumes you have the NextJS site running at localhost:3000.
• npm run cypress:run: Runs all tests. Useful for a quick sanity check before sending a PR or to run in CI pipelines.
• npm run cypress:image-baseline: If you have tests failing because of visual changes that was expected, this command will update the baseline images stored in ./cypress-visual-screenshots/baseline with those from the adjacent comparison folder. More can be found in the docs of uktrade/cypress-image-diff.

Read more in the ./cypress README.

Jest and React Testing Library are used for unit testing JS/TS/TSX code.

• Store unit test files adjacent to the file being tested and have the filename end with .test.ts for non-React code or .test.tsx for React code.
• npm run jest: automatically runs tests and watches for any relevant changes to rerun tests.

Read more in the ./src/README.md.

When writing code for the website, we have a few best practices:

1. When importing packages import external dependencies first then local dependencies. Order them alphabetically according to the package name.
2. When trying to implement something new, check if Chakra-UI has components that are close enough to your need. For example Sliders, Radio Buttons, Progress indicators, etc. They have a lot and we can save time by re-using what they have and tweaking the style as needed.
3. Format everything with Prettier. This is done by default with pre-submits. We currently don't have any custom settings.
4. Define functional React components (with types for all properties when feasible).

When working on new features or making significant changes that can't be done within a single Pull Request, we ask that you make use of Feature Flags.

We've set up react-feature-flags to make this easier. To get started:

1. Add a new flag entry to website/src/flags.ts. We have an example flag you can copy as an example. Be sure to isActive to true when testing your features but false when submitting your PR.
2. Use your flag wherever you add a new UI element. This can be done with:

import { Flags } from "react-feature-flags";
...
      <Flags authorizedFlags={["yourFlagName"]}>
        <YourNewComponent />
      </Flags>

You can see an example of how this works by checking `website/src/components/Header/Headers.tsx` where we use `flagTest`.

1. Once you've finished building out the feature and it is ready for everyone to use, it's safe to remove the Flag wrappers around your component and the entry in flags.ts.

To use stable and consistent URL paths, we recommend the following strategy for new tasks:

1. For any task that involves writing a free-form response, put the page under website/src/pages/create with a page name matching the task type, such as initial_prompt.tsx.
2. For any task that evaluates, rates, or ranks content, put the page under website/src/pages/evaluate with a page name matching the task type such as rank_initial_prompts.tsx.

With this we'll be able to ensure these contribution pages are hidden from logged out users but accessible to logged in users.

To learn more about Next.js, take a look at the following resources:

• Next.js Documentation - learn about Next.js features and API.
• Learn Next.js - an interactive Next.js tutorial.