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

feat: LEAP-1492: More flexible Custom buttons #6454

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

hlomzik
Copy link
Collaborator

@hlomzik hlomzik commented Oct 1, 2024

  • extend the structure of custom buttons definition to allow different modes
  • custom buttons now can replace just some buttons, leaving the rest untouched
  • start to simplify work with all buttons to use standard button description + additional wrappers for main actions, so any button action will go through mandatory checks

Examples of new structure:

// switch buttons
{ "_replace": ["update", "submit"] }

// add simple custom button
{ "_before": [{ "name": "analyze", "title": "Analyze task" }] }

// split Reject into 2 buttons, leaving normal Accept button;
// these 2 new buttons share part of reject logic
{ "reject": [
  { "name": "hide", "title": "Hide" },
  { "name": "postpone", "title": "Postpone" },
] }

PR fulfills these requirements

  • Tests for the changes have been added/updated (for bug fixes/features)
  • Docs have been added/updated (for bug fixes/features)
  • Best efforts were made to ensure docs/code are concise and coherent (checked for spelling/grammatical errors, commented out code, debug logs etc.)
  • Self-reviewed and ran all changes on a local instance (for bug fixes/features)

Change has impacts in these area(s)

  • Product design
  • Backend (Database)
  • Backend (API)
  • Frontend

Describe the reason for change

We need to dynamically display buttons we need, so previous predefined approach didn't work.

Does this change affect performance?

no

Does this change affect security?

no

What alternative approaches were there?

(briefly list any if applicable)

Does this PR introduce a breaking change?

  • Yes, and covered entirely by feature flag(s)
  • Yes, and covered partially by feature flag(s)
  • No
  • Not sure (briefly explain the situation below)

What level of testing was included in the change?

  • e2e
  • integration
  • unit

- extend the structure of custom buttons definition to allow different modes
- custom buttons now can replace just some buttons, leaving the rest untouched
- start to simplify work with all buttons to use standard button description + additional wrappers for main actions, so any button action will go through mandatory checks
@github-actions github-actions bot added the feat label Oct 1, 2024
Copy link

netlify bot commented Oct 1, 2024

Deploy Preview for heartex-docs canceled.

Name Link
🔨 Latest commit 1a5ab1e
🔍 Latest deploy log https://app.netlify.com/sites/heartex-docs/deploys/66fc62c9aa29010008ebcb15

Copy link

netlify bot commented Oct 1, 2024

Deploy Preview for label-studio-docs-new-theme canceled.

Name Link
🔨 Latest commit 1a5ab1e
🔍 Latest deploy log https://app.netlify.com/sites/label-studio-docs-new-theme/deploys/66fc62c9d52e890008762d4e

Comment on lines +33 to +35
function toArray<T>(arg: undefined | T | (T | undefined)[]): T[] {
return (Array.isArray(arg) ? arg : [arg]).filter(v => v !== undefined);
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

It could be moved to utils

await onClick?.(button.name);
setWaiting(false);
}, []);
// @todo do we need waiting? all buttons should utilize isSubmitting
Copy link
Collaborator

Choose a reason for hiding this comment

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

It's for indication, but it may look not good.


// either we render _before buttons and then the rest, or we render only _replace buttons
if (firstToRender) {
const allButtons = Array.isArray(firstToRender) ? firstToRender : [firstToRender];
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
const allButtons = Array.isArray(firstToRender) ? firstToRender : [firstToRender];
const allButtons = toArray(firstToRender);

@@ -29,7 +29,8 @@ type MSTCommentStore = {
};

type MSTStore = {
customButtons: Instance<typeof CustomButton>[];
// @todo we can't import CustomButton store here and use it type :(
customButtons: any;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I've just figured out that it works for me 🤯

Suggested change
customButtons: any;
customButtons: CustomControlProps.button[];

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

Successfully merging this pull request may close these issues.

2 participants