Handle hidden field state by hiding reason and distinguish revealed questions
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 48/100
Research direction
No files or tests are named. Start by tracing hidden-field state handling and the “show questions that were hidden” flow, then verify that rule-hidden fields become unanswered, benefit-determined fields preserve their prior state, and revealed questions are visually distinct from active ones.
Written by the indexing model from the issue text.
Description
Desired behavior
Hidden fields should be treated differently depending on why they are hidden:
- Hidden by a user-defined rule on the field: consider the field unanswered/null. (I believe this is the default in
form-js) - Hidden because all associated benefits have been determined: preserve the state the field had before it was hidden, whether answered, unanswered, or another state.
When the user toggles “show questions that were hidden”, questions that would otherwise be hidden should be visually differentiated from questions that are still in play. Possible treatments include muted/greyed styling, italics, or a visible tag; the specific treatment is open for design discussion.
Acceptance criteria
- Rule-hidden fields are considered unanswered/null.
- Fields hidden because all associated benefits have been determined retain their prior state.
- Revealing otherwise-hidden questions clearly distinguishes them from questions still in play.
Related: #503
- Dominant language
- Java
- Stars
- 16
- Forks
- 5
- Avg merge
- 1d 26m
- Merged PRs (30d)
- 25
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
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 CodeForPhilly/benefit-decision-toolkit
-
documentation Good for newcomer quick win
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
CodeForPhilly/benefit-decision-toolkit#519 ·
Maintainers usually reply within 1 day
-
documentation quick win
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
CodeForPhilly/benefit-decision-toolkit#445 ·
Maintainers usually reply within 1 day
-
Make issue templatesOpen
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
CodeForPhilly/benefit-decision-toolkit#425 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
CodeForPhilly/benefit-decision-toolkit#525 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
CodeForPhilly/benefit-decision-toolkit#524 ·
Maintainers usually reply within 1 day
All issues in CodeForPhilly/benefit-decision-toolkit
Similar issues
-
link-check link-check:manual
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
-
Difficulty 1/5 Under an hour Newbie friendliness 91/100
open-telemetry/opentelemetry-java#8870 ·
Maintainers usually reply within 1 day
-
P2 testing
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
enhancement javascript
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
area/core kind/bug status/triage team/core-shared
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day