BUILD STUDIO / WEB ENGINEERING
Order Desk
A typed React application with real boundaries
Repair a running multi-file app, control competing requests, and write tests that can prove your first solution wrong.
Browser smoke tests execute selected pure TypeScript modules after syntax-only transpilation. React rendering, semantic typechecking, full Node tests and UI tests run in the downloaded project. No network service or authentication is supplied.
Opening your workspace…
The small project source is loaded only when this workspace opens.
Original project brief and legacy stage notes
Cross-academy build · 5 substantial stages
Build a production-style study board
Create an accessible team study-board application with typed requests, a real development database, scoped authentication, tests and a reviewable deployment artifact. Keep production services optional until the project needs a deliberate release.
This is a project brief and local evidence notebook. Implement the project in your own development repository using synthetic data. Checklists and the review question record self-review; LearnLab does not execute these project files, inspect a live database, grade the implementation or certify security. Starter snippets are deliberately partial. Link actual commands, outputs, revisions and screenshots to your notes. Publishing requires a separate deliberate release decision.
Skills this project brings together
- A form is state, semantics and feedback
- Effects synchronize with something outside React
- A type is a promise; a boundary needs evidence
- Ask where and when this code runs
- Choose rendering by freshness, authority and cost
- A cache key is a claim that two answers are interchangeable
- Deploy the artifact you actually verified
- Measure the experience and prove the offline boundary
- Turn access claims into falsifiable tests
- Give each browser defense its own job
- Make verification reproducible and honest
- A release claim needs a source snapshot and an artifact
Implementation stage · self-review
1. Design one useful feature and its runtimes
A study group can create tasks, assign an optional owner and mark tasks complete. Public help content is prebuilt; protected task data belongs to authenticated group members. Choose static frontend plus a separate authorized data API, or a compatible request runtime, and explain the choice.
Acceptance criteria
Mark an item only after you have reviewed the corresponding implementation and evidence. These are your declarations, not automated test results.
Concrete tests to run
- Group A has Alice/editor and an auditor/reader; Group B has Bob/editor.
- The same task title may exist in different groups without merging their identity.
- A public help route is available without authentication, while private task data requires its own authority check.
- The chosen hosting configuration supports every required runtime operation.
If local development works but the exported application has no working write endpoint, revisit the hosting/runtime boundary before debugging form styling.
Open the partial starter
const boundaries = {
build: ['public help and application shell'],
browser: ['form state', 'focus', 'request lifecycle'],
trustedDataAPI: ['identity', 'group authorization', 'atomic writes']
};
// Choose actual implementations compatible with the deployment contract.This fragment frames the next design decision. It is not a finished implementation.
Your evidence notebook
This notebook stores text and review declarations. It does not execute files, grade a capstone, grant mastery, or publish an application. Up to 50 recent learning drafts are retained; export a backup for longer-term work.