Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Volto form block fixes #6370

Open
wants to merge 60 commits into
base: main
Choose a base branch
from
Open

Volto form block fixes #6370

wants to merge 60 commits into from

Conversation

robgietema
Copy link
Member

@robgietema robgietema commented Oct 3, 2024


If your pull request closes an open issue, include the exact text below, immediately followed by the issue number. When your pull request gets merged, then that issue will close automatically.

Closes #

Copy link

netlify bot commented Oct 3, 2024

Deploy Preview for plone-components canceled.

Name Link
🔨 Latest commit e126278
🔍 Latest deploy log https://app.netlify.com/sites/plone-components/deploys/67d16d6ddd56220008c28f52

Copy link
Member

@davisagli davisagli left a comment

Choose a reason for hiding this comment

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

Please add release notes and fix the lint errors and failing unit tests.

@davisagli davisagli requested a review from sneridagh October 4, 2024 00:59
@stevepiercy
Copy link
Collaborator

This PR should also render its Storybook. We recently merged a PR that should fix the pull request preview build on Netlify:
#6410

The Netlify build currently fails to recognize changes in the most recent commit:
https://app.netlify.com/sites/plone-components/deploys/670fb4bff3f6740008e0d09f

@robgietema robgietema force-pushed the volto-form-block-fixes branch 2 times, most recently from 6d9bc8a to be53373 Compare November 5, 2024 12:55
@robgietema robgietema force-pushed the volto-form-block-fixes branch from 988b47e to dd5a050 Compare December 20, 2024 18:55
Copy link
Member

@davisagli davisagli left a comment

Choose a reason for hiding this comment

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

In general this has a lot of useful improvements, but still some rough edges and missing docs.

type: 'string',
title: intl.formatMessage(messages.queryParameterName),
description: intl.formatMessage(messages.queryParameterNameDescription),
},
Copy link
Member

Choose a reason for hiding this comment

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

I tried adding a queryParameterName to a field in a content type schema, but it doesn't do anything.

Copy link
Member Author

Choose a reason for hiding this comment

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

It's a property of the field which can be used by the actual view (or not). In this case the content type schema editing view doesn't use it but could in the future.

Copy link
Member

Choose a reason for hiding this comment

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

If it doesn't do anything, it's bad UX to show it when editing a content type schema in the schemaeditor.

Copy link
Member Author

Choose a reason for hiding this comment

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

I disagree, the schema widget is not tied to a specific form library and set of widgets. You can decide to use your own set of widgets which do make use of these values. This is not something new in Plone, there are plenty of fields on a content type or settings in the control panels which are not used by stock plone or shown in the ui but can be used if somebody wants that.

placeholder: {
type: 'string',
title: intl.formatMessage(messages.placeholder),
},
Copy link
Member

Choose a reason for hiding this comment

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

I tried adding a placeholder to a text field in a content type schema, but it didn't show up when I edited the content type.

Copy link
Member Author

Choose a reason for hiding this comment

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

It's a property of the field which can be used by the widget (or not). In this case the current widget in Plone doesn't use the value but when you use a custom widget (react-aria-components for example) you can use those properties.

Copy link
Member

Choose a reason for hiding this comment

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

We can't just add properties to the schema editor that look useful but don't do anything. That's a recipe for frustration!

Copy link
Member Author

Choose a reason for hiding this comment

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

See above comment.

Copy link
Collaborator

@stevepiercy stevepiercy left a comment

Choose a reason for hiding this comment

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

Minor MyST enhancements.

@sneridagh sneridagh requested a review from a team March 12, 2025 10:36
Copy link
Member

@sneridagh sneridagh left a comment

Choose a reason for hiding this comment

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

Some small comments, humongous work! Congrats!

* @function RadioGroupWidget
* @returns {string} Markup of the component.
*/
class RadioGroupWidget extends Component {
Copy link
Member

Choose a reason for hiding this comment

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

+1

id="fieldset-default-field-label-my-field"
>
My field
</label>
Copy link
Member

Choose a reason for hiding this comment

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

I don't see the vocabulary being passed in the test.

@sneridagh sneridagh requested a review from a team March 13, 2025 08:07
Copy link
Contributor

@pnicolli pnicolli left a comment

Choose a reason for hiding this comment

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

Huge and very very useful work, thanks!!!! Left a few notes with the goal of having this as polished as possible.

Comment on lines +1089 to +1090
basic
secondary
Copy link
Contributor

Choose a reason for hiding this comment

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

I'm worried these props could be spread unknowingly to the final html <button> that is rendered, if the provided custom button does not handle them, and it is likely that this is the case because Button components are usually handling a bunch of props and assuming other props are standard html and just spread them in the html button. This causes annoying warnings in the browser console telling you you are using unknown attributes.

I would try to set these (and others like floated) only if a custom button is not provided, maybe by creating smaller preset buttons above, at line 740, or even outside of this component. Ideas or thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

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

This is not a blocker for me, but I would honestly not create new components as class components ever again, unless there is a specific reason, for example asyncConnect which acts weird in function components.


export const CheckboxGroupWidgetComponent = injectIntl(CheckboxGroupWidget);

export default compose(
Copy link
Contributor

Choose a reason for hiding this comment

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

If we keep the class component here, I would remove the compose call here since there is only one function being composed


export const RadioGroupWidgetComponent = injectIntl(RadioGroupWidget);

export default compose(
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here, I would remove the useless compose call here

Copy link
Contributor

Choose a reason for hiding this comment

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

Do we also need views widgets for radiogroup, checkboxgroup and time widgets?

.toLowerCase()
.replace(/[\s-]+/g, '_')
.replace(/[^\w]+/g, '');
let i = 1;

if (includes(slugs, slug)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

I would also use standard js here instead of lodash

@@ -54,6 +54,10 @@
}
}

.ui.form .ui.checkbox {
margin: @8px 0;
Copy link
Contributor

Choose a reason for hiding this comment

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

@8px is a typo or is it a syntax I am not familiar with?

Comment on lines +193 to +194
map(
['URL', 'Password', 'label_password_field', 'Email', 'label_email'],
Copy link
Contributor

Choose a reason for hiding this comment

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

I would start using standard js for these easy things, instead of using lodash. Nowadays we don't need lodash for these simple things like map. Also, since we are not really using the output from map here, I would suggest simply doing

['URL', 'Password', 'label_password_field', 'Email', 'label_email'].forEach

@@ -927,6 +945,8 @@ class Form extends Component {
),
...map(item.fields, (field, index) => (
<Field
widgets={this.props.widgets}
component={this.props.component}
Copy link
Contributor

Choose a reason for hiding this comment

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

If I understand correctly, this.props.component is a Form component of some kind here, either the default or a provided one, so maybe this should not be passed to the Field component, right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants