Conversation
glasserc
left a comment
There was a problem hiding this comment.
Hi, thanks for the PR, plus your other PRs and comments, plus also your patience!
I've started to warm up to the idea of this patch. It does improve our consistency for customizing formatting and it does address some concerns raised in other issues. My main remaining concern is about whether this goes far enough, and whether the approach it takes can be applied to arrays as well as objects. But I don't see any reason why arrays would be much different, and I'm comfortable merging this and leaving arrays for later.
Remaining are basically nits.
README.md
Outdated
| The following props are passed to each `ObjectFieldTemplate`: | ||
|
|
||
| - `DescriptionField`: The generated `DescriptionField` (if you wanted to utilize it) | ||
| - `TitleField`: The generated `TitleField` (if you wanted to utilize it). |
There was a problem hiding this comment.
I'm kind of ambivalent about passing these field components to the template. Client code already has the opportunity to override the entire template, using any DescriptionField and TitleField definition they want, and they can re-import DescriptionField and TitleField themselves if they want them. So what's the value?
I don't think generated is the right word here -- it's the one taken from the registry.
How about changing if you wanted to to in case you wanted to?
There was a problem hiding this comment.
I agree that passing DescriptionField and TitleField is useless. However, ArrayField also passes them to ArrayFieldTemplate, so at least we are consistenly useless :)
I copy pasted the descriptions from ArrayFieldTemplate manual entry. I changed the descriptions in both manual entries now to "The DescriptionField/TitleField from the registry (in case you wanted to utilize it)"
README.md
Outdated
| - `formData`: The form data for the object. | ||
| - `formContext`: The `formContext` object that you passed to Form. | ||
|
|
||
| The following props are part of each element in `items`: |
There was a problem hiding this comment.
Is items here a typo for properties?
| - `name`: A string representing the property name. | ||
| - `disabled`: A boolean value stating if the object property is disabled. | ||
| - `index`: A number stating the index the property occurs in the `properties`. | ||
| - `readonly`: A boolean value stating if the property is readonly. |
README.md
Outdated
| - `children`: The html for the property's content. | ||
| - `name`: A string representing the property name. | ||
| - `disabled`: A boolean value stating if the object property is disabled. | ||
| - `index`: A number stating the index the property occurs in the `properties`. |
There was a problem hiding this comment.
I don't think we need to expose this, because it should be the same as the index in the children array, right?
test/ObjectFieldTemplate_test.js
Outdated
| <TitleField title={title} /> | ||
| <DescriptionField description={description} /> | ||
| <div> | ||
| {properties.map(({ children, idx }) => ( |
There was a problem hiding this comment.
Is idx even going to be valid here?
README.md
Outdated
|
|
||
| The following props are part of each element in `items`: | ||
|
|
||
| - `children`: The html for the property's content. |
There was a problem hiding this comment.
I don't like children as the name for this property. How about content, or rendered?
Hmm, I'm not sure I understand what you mean. The templating approach is taken directly from how
No problem, there's no hurry :). I'm using a patched private repo so I can use the code changes before my PRs get merged/handled. |
Oops. Somehow I had in my mind the idea that we were less flexible about arrays because of the question in #573. However, looking back at it, I now see that this is about ArrayWidgets, not ArrayFields or their templates, and I had confused myself. OK, great! Let me look at it again. |
glasserc
left a comment
There was a problem hiding this comment.
Looks great, just one question.
README.md
Outdated
| - `content`: The html for the property's content. | ||
| - `name`: A string representing the property name. | ||
| - `disabled`: A boolean value stating if the object property is disabled. | ||
| - `index`: A number stating the index the property occurs in the `properties`. |
There was a problem hiding this comment.
I still don't really understand why we need to expose this. Knowing that it comes from ArrayField, I can understand why it's valuable there -- but here it seems like the property name is more valuable.
There was a problem hiding this comment.
I missed this one... You're right, I removed it.
|
Thanks! |
Reasons for making this change
ObjectFieldTemplatesimplifies customizing how the fields are rendered, eg. creating a bootstrap grid layout or a flexbox layout is easier. Previously we had to override ObjectField to achieve custom layouts - likeFieldTemplateandArrayFieldTemplate, we let the users worry only about rendering. Admittedly, there isn't that much logic behindObjectField, but this pull requests adds also consistency and makes it possible to customize titles & descriptions without usingTitleFieldandDescriptionField(TitleFieldandDescriptionFieldcould be even deprecated at some point in order to make the code base more consistent - discussed in #354 also).EDIT: These issues/pull requests would be solved by this: #623 #268
Checklist
npm run cs-formaton my branch to conform my code to prettier coding style