pepkit / pepkit/pephub

UI suggestions for updating and validating

Open
#192 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

brainstorming
Dominant language
TypeScript
Stars
22
Forks
2
PR merge metrics
No merged PRs in 30d

Description

There are 2 tasks a user can do with their sample table: 1) save; 2) validate.

There are also 2 ways we can design the UI: 1) Task happens automatically on change; or 2) User must click a button to perform action.

Right now, we are doing this:

  1. For the save task, we require the user to click "Save" (not automatic).
  2. For validate, we do it automatically, on change.

One reason we made save require clicking is that it's an expensive operation that overwrites the entire project. However, with the most recent database update, samples are now stored in an independent table. This allows us to update individual samples atomically. Therefore, we should change the UI to use an onChange, send the changed sample (the raw in the table) to an endpoint to update just that sample.

Advantages:

  1. This will eliminate the need to click "save", making the UI more streamlined.
  2. This will improve performance, by only updating a sample.

For validate, though, we currently require sending the whole project, so therefore it's a more expensive task, so it's expensive to do with onChange the way it is now.

Proposed solution

If we could validate individual samples, then individual samples could be validated using the save endpoint, onchange. they could be both saved and validated on change. Eido in fact already offers a way to validate individual samples. Therefore, we could in fact just send the sample row a single time, onChange, and it could be 1) validated as a sample; and 2) saved. An equivalent thing could happen for validating the project config only, when that changes.

Then, for entire project validation, I propose the user must trigger with a button press.

I think this is probably the best way to implement the UI.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

The issue names no files or tests. Start by tracing the sample table's save and validation flows, including the save endpoint and Eido's individual-sample validation; done means sample changes save and validate on change while whole-project validation remains button-triggered.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
api, database, frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.