Skip to content

Add ObjectFieldTemplate#653

Merged
glasserc merged 10 commits intorjsf-team:masterfrom
olzraiti:objectFieldTemplate
Oct 5, 2017
Merged

Add ObjectFieldTemplate#653
glasserc merged 10 commits intorjsf-team:masterfrom
olzraiti:objectFieldTemplate

Conversation

@olzraiti
Copy link
Copy Markdown
Contributor

@olzraiti olzraiti commented Aug 1, 2017

Reasons for making this change

ObjectFieldTemplate simplifies 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 - like FieldTemplate and ArrayFieldTemplate, we let the users worry only about rendering. Admittedly, there isn't that much logic behind ObjectField, but this pull requests adds also consistency and makes it possible to customize titles & descriptions without using TitleField and DescriptionField (TitleField and DescriptionField could 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

  • I'm updating documentation
    • I've checked the rendering of the Markdown text I've added
    • If I'm adding a new section, I've updated the Table of Content
  • I'm adding or updating code
    • I've added and/or updated tests
    • I've updated docs if needed
    • I've run npm run cs-format on my branch to conform my code to prettier coding style
  • I'm adding a new feature
    • I've updated the playground with an example use of the feature

Copy link
Copy Markdown
Contributor

@glasserc glasserc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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`:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Missing blank line.

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`.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need to expose this, because it should be the same as the index in the children array, right?

<TitleField title={title} />
<DescriptionField description={description} />
<div>
{properties.map(({ children, idx }) => (
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like children as the name for this property. How about content, or rendered?

@olzraiti
Copy link
Copy Markdown
Contributor Author

olzraiti commented Sep 25, 2017

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.

Hmm, I'm not sure I understand what you mean. The templating approach is taken directly from how ArrayField handles ArrayFieldTemplate and the implementation is very similar.

Hi, thanks for the PR, plus your other PRs and comments, plus also your patience!

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.

@glasserc
Copy link
Copy Markdown
Contributor

Hmm, I'm not sure I understand what you mean. The templating approach is taken directly from how ArrayField handles ArrayFieldTemplate and the implementation is very similar.

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.

Copy link
Copy Markdown
Contributor

@glasserc glasserc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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`.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I missed this one... You're right, I removed it.

@glasserc glasserc merged commit 8e9aec5 into rjsf-team:master Oct 5, 2017
@glasserc
Copy link
Copy Markdown
Contributor

glasserc commented Oct 5, 2017

Thanks!

@glasserc glasserc mentioned this pull request Nov 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants