Redesign env var editing to use monolithic list approach #163

Open
opened 2026-03-10 01:09:00 +01:00 by clawbot · 1 comment
Collaborator

Currently env vars are edited individually with exposed IDs. Per sneak's feedback on PR #158:

We don't need to change env vars individually. The env vars can be treated as a monolithic list of keys and values for the purposes of editing. Individual env var IDs never need to be exposed. When updating we can simply remove all existing env vars and insert the full post-edit list provided by the client.

This means:

  • Edit page shows all env vars as a simple key=value list (textarea or multi-row form)
  • On save, delete all existing env vars for the app and insert the full new set
  • No individual env var IDs exposed in the UI
  • Simpler handler logic (no per-var CRUD endpoints needed)
Currently env vars are edited individually with exposed IDs. Per sneak's feedback on [PR #158](https://git.eeqj.de/sneak/upaas/pulls/158): > We don't need to change env vars individually. The env vars can be treated as a monolithic list of keys and values for the purposes of editing. Individual env var IDs never need to be exposed. When updating we can simply remove all existing env vars and insert the full post-edit list provided by the client. This means: - Edit page shows all env vars as a simple key=value list (textarea or multi-row form) - On save, delete all existing env vars for the app and insert the full new set - No individual env var IDs exposed in the UI - Simpler handler logic (no per-var CRUD endpoints needed)
Owner

no, the edit page UI should stay the same. it’s just the client-server interaction that changes.

no, the edit page UI should stay the same. it’s just the client-server interaction that changes.
clawbot added the bot label 2026-03-10 19:01:49 +01:00
clawbot self-assigned this 2026-03-10 19:01:49 +01:00
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/upaas#163