Closed kabaros closed 7 months ago
🚀 Deployed on https://pr-367--dhis2-data-entry.netlify.app
@tomzemp thanks for testing - I fix the issue with the transposed form with one default combo or one category. Below is how it looks. Also removed the cool 🕶️ feature toggle.
:tada: This PR is included in version 100.4.0 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
This PR implements the ability to display sections transposed, and grouped by category in the data entry app. Implements DHIS2-16132 .
transpose-different-options.webm
Default Section form - without pivoting (existing implementation)
Form pivoted (data elements moved to columns)
Single Category pivoted
Multiple categories (with one pivoted)
Data elements with different category combos
Notes about implementation
As an general approach, I aimed to decouple the display details (table, rows, columns, column and row spans) from our internal concepts (data elements, categories, category options, cocs etc...), to provide a middle layer (a matrix) that represents a form in our context. This middle layer can become the base of a form builder, for implementations that are cross-platform and other improvements in the future.
With the previous implementation, we were more than half-way there, but the data elements were tightly coupled to rows, and in turn the rows/data elements are tightly coupled to functionality like search, filters, highlighting current cell in the table etc... The next step should be to consolidate this implementation with the "normal" section form - there is a followup ticket for this: https://dhis2.atlassian.net/browse/LIBS-584
The only concept that remains metadata-aware is the
date entry field
- this was the existing design and it works well, as a self-contained component responsible of its own state, validation etc... regardless of where it appears in a form.I avoided changing the original
CategoryComboTable
and added a newPivotedCategoryComboTable
to handle the new use cases for transposing. I didn't want to change something that already works and well-tested for what's essentially an experimental new feature (i.e. not part of achieving parity with the existing app). Next step is to consolidate theses two components and the underlying matrix generation.In the grouped matrix logic, I added a special case for when there is one category and another for 1+ categories. This is needed because we need a "shadow" row in the case of more categories, this is unnecessary for one category. See the photo below, the first one has a "shadow" row (location fixed/outreach) and the categories are displayed underneath each other - this is necessary for multiple categories. In the case of one category (second table), we can do with the category being on top of the options.
Background
We are aiming to add more form configuration options as part of an initiative to provide configurations natively to data entry forms to reduce the necessity for custom forms. Users are currently building custom forms as a workaround for shortcomings of the configuration options (ability to transpose, or customise a cell design) or implementation (such to avoid issues with RTL issues). This is an RFC that describes the approach and the priorities for form configuration options. This is based on a thorough investigation by the functional design team for custom form use cases in real-life implementations. Based on that investigation, the ability to transpose forms and adding free-text descriptions were one of the main reasons people choose to go the custom forms route so we're tackling these first.
Known limitations
ToDos (future)
Related PRs: