angular: propagate the enabled state to detail renderers instead of modifying their UI schema
Maintainer thường phản hồi trong vòng 1 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 68/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Đặc tả rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- angular, typescript
- Lĩnh vực
- frontend
Hướng nghiên cứu
Start with packages/angular-material/src/library/util/detail-uischema.ts and the jsonforms-outlet, LayoutChildrenRenderPropsPipe, LayoutRenderer, array layout, object control, list-with-detail, and table renderer entry points named in the issue. Trace how enabled currently reaches React and Vue equivalents, then compare Angular's cloneDeep/setReadonly paths. Done means enabled state reaches nested detail renderers while the supplied UI schema remains unchanged.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Is your feature request related to a problem? Please describe.
Follow-up to #2628.
The Angular Material array layout, object control and list with detail disable their detail by calling setReadonly on its UI schema, which writes options.readonly: true into every control. That UI schema is the result of findUISchema, i.e. the user's options.detail or a UI schema from the uischemas registry. #2628 stopped modifying the user's object by deep cloning it first (createDetailUiSchemaResolver in packages/angular-material/src/library/util/detail-uischema.ts), but the renderers still render a modified copy instead of the given UI schema.
The other renderer sets never modify a given schema or UI schema. React and Vue hand the parent's state down as the enabled own prop of JsonFormsDispatch / DispatchRenderer, and isInherentlyEnabled (packages/core/src/mappers/util.ts) falls back to ownProps.enabled.
Downsides of the current Angular approach:
- The detail UI schema is deep cloned whenever one of its inputs changes, and the renderers need memoization so that this does not happen on every state emission.
- Toggling the enabled state produces a different UI schema.
jsonforms-outletcompares UI schemas withisEqual, so it destroys and re-creates the whole detail, losing any view state inside it, e.g. the selected tab of a nested categorization. - Nested and custom renderers receive a UI schema containing
readonlyoptions the user never wrote.
Describe the solution you'd like
Propagate the enabled state through the Angular bindings like React and Vue do, and render the detail UI schema as-is:
jsonforms-outlet: acceptenabled(already part ofOwnPropsOfRenderer) inrenderPropsand hand it to the created renderer, e.g. asdisabledonJsonFormsAbstractControl, whichgetOwnPropsalready maps toownProps.enabled.- Layout renderers: forward the enabled state to their children, e.g. via
LayoutChildrenRenderPropsPipe, so it reaches controls nested in layouts inside a detail.LayoutRenderercurrently only takeslabelandvisiblefrommapStateToLayoutProps. - Array layout, object control and list with detail: pass
enabled: this.isEnabled()along with the detail's render props and drop thecloneDeep+setReadonly. - Table renderer: same for its generated cell UI schemas, which also get
setReadonlytoday.
Describe alternatives you've considered
- Keep cloning the detail UI schema (current state since #2628). It works and no longer modifies the user's UI schema, but keeps the costs and the view re-creation described above, and stays inconsistent with the other renderer sets.
- Resolve the readonly state centrally in
@jsonforms/core(e.g. a parent-enabled lookup by path) instead of passing props down. This would avoid touching every layout, but has no precedent in the other bindings.
Package
Angular Bindings, Angular Material Renderers
Additional context
- Once nothing in Angular Material uses them anymore,
setReadonlyandunsetReadonlyin@jsonforms/core(packages/core/src/util/uischema.ts) have no remaining users and could be deprecated. - This is a behaviour change for Angular users: controls inside a detail would be disabled via the inherited enabled state instead of a
readonlyoption. For example, an enable rule on a control inside a disabled array keeps taking precedence in both approaches, but custom renderers readinguischema.options.readonlywould no longer see it.
- Ngôn ngữ chính
- TypeScript
- Star
- 2.8k
- Fork
- 423
- Merge trung bình
- 5 ngày 16 giờ
- Pull request đã merge (30 ngày)
- 9
Chuẩn bị môi trường
Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của eclipsesource/jsonforms
-
Add "append" and "prepend" slots for vue-vuetify extended renderersCó thể đã có người làm @simeyc đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
eclipsesource/jsonforms#2668 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
eclipsesource/jsonforms#2664 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
angular material
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
eclipsesource/jsonforms#2662 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
core
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
eclipsesource/jsonforms#2570 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
dev
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 50/100
eclipsesource/jsonforms#2651 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của eclipsesource/jsonforms
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
README の通知条件を実際の判定処理に合わせるCó thể đã có người làm @unhappychoice đã nhận hôm nay. Đang mởfactory:in-progress priority:medium
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
unhappychoice/oss-issue-opener#395 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug Website
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 77/100
OWASP/OWASP-Hunting#88 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
Maintainer thường phản hồi trong vòng 1 ngày