Bot sharing / gallery
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Quiet
- Tech stack
- javascript, react, typescript
- Domain
- backend, frontend, full-stack
Research direction
Start with server/src/services/AppService.ts, server/src/api/app.ts, and middleware/resource.ts to trace app storage, owner checks, and public reads; then read ui/src/page/sample/sampleEditor.tsx and samplePage.tsx for the existing viewer and clone flow. Add tests in server/test/api.test.ts, the AppService tests, and the sample page UI tests. Done means owners can publish and unpublish bots, visitors can browse and clone published bots, and private app sources remain owner-only.
Written by the indexing model from the issue text.
Description
Publish a bot (read-only) for others to view and clone. Browsing real strategies is both fun and a learning tool.
Effort: M
Migrated from ENHANCEMENTS.md (§3 Competition & community).
Implementation notes
Priority: medium — Solid community-growth feature reusing an existing UI pattern, but it's opt-in/non-core-path and touches no stability-critical simulation or auth-critical paths beyond a narrow, well-precedented public-read exception.
Purpose
Lets users publish a finished bot as read-only for anyone to view and clone, growing a community gallery beyond the fixed ui/public/samples/*.js set without server code changes for every new example — the recent sample-bot viewer (commit d276549) is the exact UX precedent to generalize.
Implementation approach
- Data model: add a
public boolean default falsecolumn to theapptable (server/src/services/AppService.ts,server/src/types/app.ts) — a new nullable/defaulted column is additive so it's safe under the no-migrations gap tracked in #142; addApp.setPublished/isPublishedmirroringsetName/setSource. - REST: extend
server/src/api/app.ts— add a toggle route (e.g.PATCH .../app/:appId/public, owner-gated likesetSource) and a new open (spectator-style, likeGET /api/app/:appId) listing endpoint, e.g.GET /api/apps/public, returning id/name/owner metadata only, backed by a newAppService.getPublished()query filteringpublic=true AND NOT deleted. Reuse the existingGET /api/app/:appIdmetadata route; add a source-read exception (currentlyrequireAppOwner-gated) that permits reads whenapp.isPublished()is true, inmiddleware/resource.ts. - UI: reuse
ui/src/page/sample/sampleEditor.tsx+samplePage.tsxpattern — either point the existing route at published apps by id (/apps/:appIdviewer) or add a parallelpublicAppPage.tsx; clone flow copiesgetSource()into a new app exactly likesamplePage.tsx's clone handler, respectingMAX_APPS_PER_ARENA/MAX_APPS_PER_USER. Add a gallery list page hitting the new listing endpoint. - No
compiler.tsbot-API surface changes; no simulation/SSE changes.
Key details to plan
- Security: publishing exposes
App.getSource()to any visitor — must NOT changerequireAppOwnerfor write/delete/compile/reboot, only add a narrowly-scoped public-read path; keep parity with the add-by-reference model already documented inarena.ts(metadata open, source owner-gated). - No MCP changes required unless gallery browsing should be exposed as an MCP tool/resource (optional, out of scope for M effort).
- Testing: extend
server/test/api.test.tsfor the new toggle/listing routes and the public-read exception; extendAppServicetests forgetPublished; UI: adaptui/test/*sample-page-style tests (mirroring the samplePage clone-flow test) for the new public-app viewer. - Determinism/SSE/simulation untouched — no risk there.
- Dependency: loosely related to #142 (DB migrations) since this is the first app-table schema change since launch; worth sequencing after or alongside it.
- Effort/risk: matches the M label — mostly CRUD + one UI page reusing an existing pattern; main risk is scoping the source-exposure surface correctly.
- Dominant language
- TypeScript
- Stars
- 0
- Forks
- 0
- Avg merge
- 8m
- Merged PRs (30d)
- 8
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from LeeAdcock/robocodeJs.com
-
priority: medium tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
LeeAdcock/robocodeJs.com#411 ·
Maintainers usually reply within 1 day
-
enhancement priority: medium
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
LeeAdcock/robocodeJs.com#254 ·
Maintainers usually reply within 1 day
-
good first issue priority: low tech-debt
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
LeeAdcock/robocodeJs.com#146 ·
Maintainers usually reply within 1 day
-
dependencies priority: low tech-debt
Difficulty 1/5 Under an hour Newbie friendliness 15/100
LeeAdcock/robocodeJs.com#413 ·
Maintainers usually reply within 1 day
-
priority: low tech-debt
Difficulty 3/5 Half a day Newbie friendliness 32/100
LeeAdcock/robocodeJs.com#412 ·
Maintainers usually reply within 1 day
All issues in LeeAdcock/robocodeJs.com
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
homarr-labs/homarr#7191 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
AvaProtocol/ava-sdk-js#276 ·
Maintainers usually reply within 1 day
-
useFragment does not require `variables` when the fragment's variables type has required fieldsOpen
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
apollographql/apollo-client#13493 ·
Maintainers usually reply within 1 day