codecrafters-io / frontend

Rebuild complex systems from scratch

codecrafters-frontend

The front-end app that powers app.codecrafters.io.

Prerequisites

You will need the following things installed on your computer:

• Git
• Node.js (with npm)
• Ember CLI
• Google Chrome

You can run tests locally without a backend server, but to use the app you'll also need an instance of codecrafters-io/core running. You can either run this against staging, or against a local instance of core. Visit the core repo for setup instructions.

Setup / Installation

• git clone <repository-url> this repository
• cd frontend
• npm install
• Copy .env.example to .env and fill in the values

Running / Development

• make serve
• Visit your app at https://.ccdev.dev.
• Visit your app at http://localhost:4200.
• Visit your tests at http://localhost:4200/tests.

Running against staging

• Run BACKEND_URL="https://backend-staging.codecrafters.io" npm run start
• View your app at http://localhost:4200

Running with or without FastBoot

• FastBoot is enabled when running ember build --environment=production
  • Pre-rendering is done only for routes configured under prember section in ember-cli-build.js
• FastBoot is enabled for all routes when running ember server
  • To disable it, run FASTBOOT_DISABLED=true ember server
  • Alternatively, append ?fastboot=false query parameter to each request URL
• Add FASTBOOT_DISABLED=true to your local .env file to disable FastBoot completely
  • You can override it by passing FASTBOOT_DISABLED="" in the command line
• NPM tasks start and start:ember run with FastBoot disabled
• NPM tasks start:fastboot and start:ember:fastboot run with FastBoot enabled

Running tests

• Run make serve, ensure your server is running
• View your tests at http://localhost:4200/tests/index/html?moduleId=abcd.
• Select the module(s) you want to run from the dropdown at the top right of the page & click "Apply" to run tests.
• To run all tests, remove the ?moduleId=abcd query parameter from the URL.

Linting

• npm run lint
• npm run lint:fix

Analyzing bundle size

• Run ANALYZE_BUNDLE=true ember server --environment=production

Building

• npm exec ember build (development)
• npm run build (production)

Deploying

• This app is automatically deployed to app.codecrafters.io when a commit is merged into master.
• Each branch is also deployed to a preview URL via Vercel.

frontend's Issues

Sweep: Remove "community" link from account dropdown

Let's remove the "Community" link from the account dropdown.

The file to edit is app/components/header/account-dropdown.hbs

Sweep: Rename "Referrals" link in account dropdown

Let's rename the "Referrals" link to "Refer & Earn"

The file to be edited is app/components/header/account-dropdown.hbs

Setup cloudflare pages deployment

We ran into a pretty scary bug on Vercel (still yet to know if it's us or them), and we'd like to be prepared for this in the future. Let's see if we can make our deployment work on cloudflare pages - including the pre-rendering, redirects, middleware etc.

@VasylMarchuk I've invited you to our cloudflare pages account. Feel free to purchase a domain if you need it for testing.

Use CodeMirror for rendering code/diffs

Currently, our code rendering system is built in-house using Shiki for code highlighting. Some features we've added on top of this are:

• Support for rendering diffs (green/red background for lines, +/- icons etc.)
• Support for expanding/collapsing unchanged diff sections
• Support for rendering comments (comment icons, expand/collapse comments etc.)

This is getting hard for us to extend, mostly because there isn't a solid foundation that is oriented around code editing. Let's transition away from this and use CodeMirror instead.

Rationale

We're already running into some limitations with the current system.

Current work

One example of a current limitation is the way we handle comments.

Our comment buttons are currently anchored to the right of a line, so in most cases they're hidden by default. Even if you scroll to them, the disappear when you scroll back to read the comment:

Screen.Recording.2024-01-29.at.17.44.47.mov

We want to them to be anchored to the right-most end of the editor container (not the line), like with Repl.it:

Screen.Recording.2024-01-29.at.17.43.05.mov

This is non-trivial to implement from scratch, since they need to be absolutely positioned wrt. the editor container in such a way that they're aware of a line's current Y-index. With CodeMirror, this'll be easier to do by using a system similar to their "gutter" feature (that renders icons on the left side, not right). You'll see that repl-it is using some kind of gutters plugin too.

Future work

A lot of the features we want to build in the future will be easier to build if we're using CodeMirror.

• Select text and click on "explain this"
• CodeIntelligence like GitHub, where you hover over a method and it shows you references, go-to defn. etc.
• Displaying line numbers along with diffs

We might also add an in-browser editor at some point (thought it's unlikely that'll happen soon).

Scope

For starters, let's not add any new features but transition our existing features to use CodeMirror. I'm ordering these based on least used -> most used (we should ship PRs for the least used first, so we can iron out any issues early on before shipping)

1. Rendering buildpack code: URL

This only renders code, no diffs. No expand/collapse functionality, no comments functionality.

2. Rendering Submission Diffs for admins: URL

This renders diffs, but without comments etc. Needs to support expanding/collapsing unchanged lines, but doesn't need to support comments.

3. Rendering first stage solution diffs: URL

Similar to the above.

4. Community Solution Diffs: URL

This is the most complicated one: needs diffs + comments + collapse/expand unchanged sections.

Sweep: Change "Members community for Q&A" to "Community features"

In the pricing page cards, we currently say "Members community for Q&A" as one of the feature descriptions. Let's change this to say "Community features" instead.

The file to make the changes in is app/components/pay-page/pricing-card.js.

Dark Mode - foundations

We've got a couple of pages / areas within pages that are currently in dark mode.

Examples:

• https://app.codecrafters.io/badges
• https://app.codecrafters.io/contests/weekly-7

Our styling relies on Tailwind's Dark mode feature.

We want to add dark mode throughout the app, but will do so incrementally since there'll be multiple components that need to be edited to make things look good.

As part of this task, let's add the "foundation" for this.

• We need dark mode state to be stored in local storage. The options are "light", "dark" and "system". The default will be "light".
• For staff, we need a way to toggle this in the UI. Let's add another link to account dropdown here, below the Test Sentry link.
• When this is toggled, we need the "dark" class to be applied / removed from the application layout.
• Cleanup the is-dark-mode modifier - currently it's pretty hacky, uses intersectionobserver and what not
• Cleanup the colorScheme service, it currently uses hardcoded rules based on routes
• Bonus: figure out if there's a way to prevent white flashes on reload due to fastboot (I expect this'll happen?)

Feel free to change the whole structure as much as you like, no need to stick to what we have already - most of this was added in a hurry and not properly thought out.

Note: We need all of this to work in such a way that customers aren't affected, but staff can toggle this at any time and inspect how things look. At the same time, once a staff switches things back to "light" mode, this should be treated the same as a regular user's browser. It's okay for badges, contests etc. to always be in dark mode, we aren't going to support light mode for those endpoints anytime soon.

Fix flaky test with code examples list

Example run: https://github.com/codecrafters-io/frontend/pull/1476/checks?check_run_id=22935189969

Investigate extra `await settled` and `await animationsSettled` calls in tests

Brief

Several tests require explicit extra await settled and/or await animationsSettled calls, even when using only settled-aware methods and after properly awaiting on them.

Details

• 8 extra await settled calls existed before ember-data upgrade
• 9 more were added during ember-data upgrade: #974
• 2 more were added during embroider upgrade: #991
• extra await settled calls are usually accompanied by await animationsSettled calls
• a significant part of the extra calls happens to be in GitHub-related tests

Fix test failure

@VasylMarchuk creating this so you can leave any questions/progress updates on the test failure task 🙂

Try moving to Bun

Let's try moving to Bun for package management. I tried it once long ago but there were compatibility issues.

Let's also change the CI workflow to run on GitHub actions directly instead of namespace.so (we have some weird caching setup there that seems to cause problems when deps change).

Revive user profile OG images

Earlier, we used to have OG images for user profile pages.

Example profile page: https://app.codecrafters.io/users/rohitpaulk

Example URL for an OG image: https://og.codecrafters.io/api/user_profile/8373d847-7cea-457c-94e2-7a1769d51cd6.png.

This worked only because previously the request hit our backend app first, it could convert the username to a user ID and insert the OG image tag into the rendered index.html.

Now that we're serving the front-end directly from Vercel, we'll need to do something different to revive this. I've changed the OG images URL to accept usernames too, so this should work now: https://og.codecrafters.io/api/user_profile/rohitpaulk.png.

Let's see what we can do to make these OG images work with the new app - maybe we could use Vercel middleware or something like that to fetch the username from the path and insert the OG image tag into the response for this route specifically?

Upgrade to Ember 5

Tasks

Beta Give feedback

1. Clear muted deprecation warnings
2. Fix deprecations that are dropped in Ember 5
3. Upgrade addons causing deprecation warnings
4. Mute remaining deprecation warnings
5. Run ember-cli-upgrade
6. Fix all dependency problems after upgrade
7. Fix all test errors after upgrade

Fix new ember lint errors

#1166

Enable syntax highlighting in tests

In the test environment, we have syntax highlighting disabled:

frontend/app/lib/highlighter-cache.js

Line 17 in e2aab06

if (config.environment === 'test' || !window.fetch || !window.XMLHttpRequest) {

. This is because pretender seems to interfere with wasm requests and return invalid contents back. Can we see if there's a way to enable this and bypass pretender?

Fix ember-data warnings when using `findRecord` with a `slug` instead of `id`

Brief

When our app/routes/concept-group.ts route fetches a concept-group model using findRecord, it passes it a slug (rust-primer) instead of id — but the back-end returns a record with id: ca1df9fa-e8e4-4955-bea9-cc09f205ff9c.

this.store.findRecord('concept-group', params.concept_group_slug, { include: 'author' })

This leads to two following ember-data warnings:

Details

When changed to using queryRecord as suggested, and passing the slug as a query parameter:

this.store.queryRecord('concept-group', { slug: params.concept_group_slug, include: 'author' })

The following problem occurs:

More details

The difference in the API request URLs is:

https://backend-staging.codecrafters.io/api/v1/concept-groups/rust-primer?include=author
https://backend-staging.codecrafters.io/api/v1/concept-groups?include=author&slug=rust-primer

The Problem

The API returns a collection (array) instead of a primary object (one item), because slug is in query params instead of being in the route path as ID would be.

How should API differentiate between store.query and store.queryRecord requests, when the former expects an array, while the latter expects one object, but there's no way to tell from the URL which method was used?

"Update available" flow

🚧 WIP

Problem

We occasionally need to ship backend changes that are incompatible with new frontend versions.

How we handle this currently

Until now our approach has been to keep changes backward compatible for a week or so, and then remove the backward compatibility code after.

Requirements

We'd like to have a way to notify users that an update is available. We don't want to do this on every update, only on ones that where we manually make a version bump.