Altinn / Altinn/app-frontend-react
List component: remaining issues
- Dominant language
- TypeScript
- Stars
- 21
- Forks
- 33
- Avg merge
- 6d 23h
- Merged PRs (30d)
- 3
Description
## Description
The `List` form layout component has been implemented mostly from external contributions from `org/pat`. While they implemented most of the functionality they needed, some things remain from our list of functional requirements. Copied over from #638, this list contains the remaining requirements.
## Related Issue(s)
- #578
### Requirements
- [ ] The component can be configured with a static data source, much like existing options/code lists.
- For static data defined in the layout file, sorting can only work on alphabetically sorting strings.
- [ ] A row in the List component can be configured to as behaving as a multi-select. This means a checkbox will show up as the first column in the table view. If this is used instead of a radio button, the data model binding should be interpreted as a `list` data model binding (as used for attachments), i.e. it will store data in an array. It might also be required to interpret the data model binding as a `group` binding (i.e. prefilling/populating a repeating group structure).
- [ ] Support for the component in repeating groups, using the Summary value in the table header
- [ ] Support for 'required', with proper/intuitive validation messages when no row is selected
- [ ] Support for 'readOnly'?
- [ ] Bugfix: Handlechange is called in a loop, sometimes causing race condition when you have multiple datamodel bindings. Sometimes only one of the datamodelbindings are saved correctly.
- Partly fixed in #899, as it no longer causes data corruption, but we still send multiple requests
- [ ] Create issue(s) for implementing support for this component in Altinn Studio
Consider extracting some of these out to separate issues if work starts on one or more of these tasks.
Contributor guide
Research direction
Start by reviewing the existing List component and related issues #638, #578, and #899. Split the unchecked requirements into separate, scoped tasks before starting; completion should be defined independently for each requirement, including its validation or data-binding behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- react, typescript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100