Add ADR for the State collection (#723) - #735
Conversation
|
Record the decision to introduce a `State` collection (`valid`, `invalid`, `warning`, `changed`) and rename the form-field prop `validationState` to `state`, as the first architecture decision record in this project.
7e4e8ce to
02c8c49
Compare
|
|
||
| ## Open questions | ||
|
|
||
| 1. **Do #711 and #712 ride along?** All three rework the same rendering block, |
There was a problem hiding this comment.
I think they should be a separate commit in the same release so consumers only deal with BC change once.
| 2. **Is `changed` the right word?** Alternatives: `modified`, `unsaved` (names | ||
| the workflow rather than the element), `dirty` (React jargon, reads poorly in | ||
| end-user documentation). Hard to change later. | ||
| 3. **Which hue?** Every blue-ish slot is taken (`note` and `selected` `#007bff`, |
There was a problem hiding this comment.
The consumer apps generally speaking redefine these, so I would let @adamkudrna pick whatever he likes.
| what #712 is about, and their order is what #711 is about. Folding them together | ||
| would destroy the distinction those issues exist to sharpen. | ||
|
|
||
| ## Alternatives considered |
There was a problem hiding this comment.
I'm unsure about the relationship of the members of the state dictionary. Should they be mutually exclusive?
If we go with the proposal, then the usage would be:
invalid: used for modified and unmodified data that fail validationwarning: used for modified and unmodified data that fail validation sofltyvalid: unusedchanged: used for changed and valid data (as invalid data use theinvalidstate)
This seems somehow asymmetrical to me.
@adamkudrna what arguments do we have against using valid for modified and valid?
| the same `surrounding-text-color` token and the same documentation sections. | ||
| One breaking-change window means dependent projects migrate once instead of | ||
| twice; separate PRs are cleaner to review. Leaning towards bundling. | ||
| 2. **Is `changed` the right word?** Alternatives: `modified`, `unsaved` (names |
There was a problem hiding this comment.
I would go with either changed or modified. I have no clear preference between these two.
| - CSS Guidelines: 'docs/contribute/css.md' | ||
| - Releasing: 'docs/contribute/releasing.md' | ||
| - Decisions: | ||
| - '1. State Collection': 'docs/contribute/decisions/0001-state-collection.md' |
There was a problem hiding this comment.
I like having the ADRs public
|
|
||
| ## Open questions | ||
|
|
||
| 1. **Do #711 and #712 ride along?** All three rework the same rendering block, |

Records the decision to introduce a
Statecollection (valid,invalid,warning,changed) and to rename the form-field propvalidationStatetostate, as the first architecture decision record in this project.This is the record of the decision only — no implementation. Relates to #723, but deliberately does not close it: the
changedstate itself is still to be built.What's here
src/docs/contribute/decisions/0001-state-collection.md— the ADR, status Proposed.mkdocs.yml— a new Decisions group under Guides › Contribute, so the page isn't an orphan in the nav.Open questions in the ADR
The document ends with four questions that need a decision before implementation starts:
helpTextandvalidationTextorder #711 andhelpTextcolor #712 ride along in the same breaking-change window?changedthe right word (vs.modified,unsaved,dirty)?--rui-color-state-changed? Every blue-ish slot is taken.Cardland in the same change or a follow-up?Notes
npm run lint,mkdocs build,npm run buildandnpm run test:jestall pass.npm run test:playwright-ct:allcould not run — theplaywrightcontainer aborts withEBADDEVENGINES(Node v24.17.0 vs. the^22.23.0 || ^24.19.0pin from dd332ed). This is pre-existing onmasterand unrelated to this change; the container image likely needs rebuilding.