-
Notifications
You must be signed in to change notification settings - Fork 910
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
feat(pieces-form): add separator, title, group #3206
base: main
Are you sure you want to change the base?
feat(pieces-form): add separator, title, group #3206
Conversation
☁️ Nx Cloud ReportCI is running/has finished running commands for commit 6f6f1d2. As they complete they will appear below. Click to see the status, the terminal output, and the build insights. 📂 See all runs for this CI Pipeline Execution
✅ Successfully ran 2 targetsSent with 💌 from NxCloud. |
Nice, @Doskyft! The first picture seems like a group, and the second one looks like a title with a separator—kind of like creating a form group on the frontend, which makes sense. I'm curious, though, about why someone would prefer Title + Separator over a Group. Any specific reasons or examples you have in mind? What's your take on this? One drawback of having both is that it might confuse contributors about which props to use. Eventually, we could end up with a mix of opinions, leading to confusion or inconsistency from the end user's perspective. In my view, the frontend for activepieces should have a clear opinion on how things are displayed, making it easier to apply new learnings across all pieces. However, if the functionality differs, we should support the prop. In a group, I see it as more functional, eliminating the need for contributors to spread the object over many properties and assemble them in the code, as in the example you mentioned. |
Hello @abuaboud, I must admit that I didn't delve deeply into this matter. In the logic I had in mind, for instance, mandatory fields could always be displayed, but if there are many, they could be separated by separators or titles, while groups could be used for more optional fields. Additionally, it's worth noting that separators can also be utilized within groups for further organization. However, while creating these different options, I leaned more towards the idea of allowing the piece creator the freedom to choose what they prefer. Yet, I realize that for the end user, this could be confusing in some cases if separators are used without a common logic. If you believe that it would be better to keep only the groups, I am completely willing to proceed in that manner. I will then remove the other two options without any issue! For more precision here is the code for the corresponding part import {createAction, Property, PropertyStyle} from "@activepieces/pieces-framework";
export const demoAction = createAction({
name: 'demo',
displayName: "Demo",
description: "This is a demo action",
props: {
user: PropertyStyle.Group({
displayName: 'User',
props: {
name: Property.ShortText({
displayName: 'Name',
description: 'The name of the member',
required: true,
}),
sep: PropertyStyle.Separator(),
email: Property.ShortText({
displayName: 'Email',
description: 'The email of the member',
required: true,
}),
security: PropertyStyle.Title({
displayName: 'Security',
}),
password: Property.ShortText({
displayName: 'Password',
description: 'The password of the member',
required: true,
})
}
}),
},
async run (context) {
}
}) |
…ma-opensource/enhancement-pieces-form-add-separator
…hancement-pieces-form-add-separator
@Doskyft Great perspective, Let's me try to get other team mates opinions and get back to you I am being extra careful as these options are not easy to revert back once pieces start using it |
…hancement-pieces-form-add-separator
Hello !
I am currently working on the creation of a piece which contains A LOT of fields, to improve the experience, I added "PropertyStyle", to be able to separate and group the fields together.
A small breaking change, mandatory fields are no longer put first.
Example