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

refactor(FR-357): NEO configurations page using Setting List #3077

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

Conversation

nowgnuesLee
Copy link
Contributor

@nowgnuesLee nowgnuesLee commented Jan 26, 2025

resolves #3015 (FR-357)

changes

  • Changed configurations items into react SettingList component
  • Update modal design to current design system. Enable to auto-save and delete fuctionality.
  • Changed notification to message
  • add Save button and validate.
  • add note component on upside.
스크린샷 2025-02-17 오후 2 48 01 스크린샷 2025-02-17 오후 2 48 15 스크린샷 2025-02-17 오후 2 48 22 스크린샷 2025-02-17 오후 2 48 50

Checklist: (if applicable)

  • Documentation
  • Minium required manager version
  • Specific setting for review (eg., KB link, endpoint or how to setup)
  • Minimum requirements to check during review
  • Test case(s) to demonstrate the difference of before/after

Copy link

graphite-app bot commented Jan 26, 2025

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

  • flow:merge-queue - adds this PR to the back of the merge queue
  • flow:hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has required the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

@github-actions github-actions bot added the size:L 100~500 LoC label Jan 26, 2025
Copy link

github-actions bot commented Jan 26, 2025

Coverage report for ./react

Action wasn't able to generate report within GitHub comment limit. If you're facing this issue, please let me know by commenting under this issue.

Report generated by 🧪jest coverage report action from 5379e43

@github-actions github-actions bot added area:ux UI / UX issue. area:i18n Localization size:XL 500~ LoC and removed size:L 100~500 LoC labels Feb 4, 2025
@nowgnuesLee nowgnuesLee marked this pull request as ready for review February 4, 2025 07:07
@nowgnuesLee nowgnuesLee marked this pull request as draft February 5, 2025 06:57
@nowgnuesLee nowgnuesLee marked this pull request as ready for review February 5, 2025 07:54
Copy link
Contributor

@agatha197 agatha197 left a comment

Choose a reason for hiding this comment

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

Please resolve the conflicts. And the margin between the text and the button is too narrow. Let's enlarge it.
image

Copy link
Contributor

@lizable lizable left a comment

Choose a reason for hiding this comment

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

I have a several requests to change before this PR is merged.

  1. Update on-the-fly
    I'm not sure update on blur event is a good choice or not.
    In both "overlay network" setting and "scheduler". I think is better to have "update" button to click so that they know what they've been changed, explicitly. Besides, everytime input field is on blur, update happens; which makes continuous update requests with snackbar, which seems a bit distracted. Therefore I guess It's better to have "update" button in the modal for user to request explicitly. If you have any other options, please tell us.
    Screen Recording 2025-02-13 at 5.44.59 PM.mov (uploaded via Graphite)

  2. Would Snackbar notification is the best option?
    I'm not sure about this either...probably after updating the request from above will make it okay, but I think we should make the height of notification(snack bar) little bit shortened than current status. I think is too big to distract the changes.

Copy link
Contributor Author

I think so. Previously, a warning modal would appear when user doesn't save the value and close it, but I removed that modal and changed it to save on-the-fly using onBlur (related thread. What do you think about displaying a warning message above instead of the warning modal? I think it would be better. After that let's add update button.

I used that notification due to the previous legacy. How about using the message feature from App.useApp() instead?

@nowgnuesLee nowgnuesLee requested a review from lizable February 17, 2025 05:51
Copy link
Contributor

@lizable lizable left a comment

Choose a reason for hiding this comment

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

@nowgnuesLee It would be nice to fix the conflict so that I can review this :)

@@ -354,7 +357,11 @@ const router = createBrowserRouter([
},
{
path: '/settings',
handle: { labelKey: 'webui.menu.Configurations' },
Copy link
Member

Choose a reason for hiding this comment

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

Please recover handle. It's for display breadcrumb title.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, I'm sorry. I'll recover it.

);
if (result === 'ok') {
updatePulling();
message.success(t('notification.SuccessfullyUpdated'));
Copy link
Member

Choose a reason for hiding this comment

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

It's not a good idea to call a function to render the UI (e.g., message.success). My suggestion is to remove useBAIConfigurationSettings and move all the logic from this file to each item in ConfigurationSettingList.tsx. Since the logic for each item is neither lengthy nor dependent, it would be better to keep the related code close together to enhance readability.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I had been thinking about it as well, but your suggestion has made it clearer. Thank you.

Comment on lines 83 to 84
...selectProps?.style,
marginTop: token.marginXS,
Copy link
Member

Choose a reason for hiding this comment

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

The style from the prop should have higher priority. More specifically defined styles should take precedence.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you! I'll fix it up.

<Flex>
{labels[key]}
<Tooltip title={tooltipText[key]}>
<Button type="link" icon={<InfoCircleOutlined />} />
Copy link
Member

Choose a reason for hiding this comment

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

Form.Item has 'tooltip` prop. Please use it. :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Oh, I didn't know about it. Thank you for pointing that out. :)

Comment on lines 92 to 118
<Form.Item
label={
<Flex>
{labels[key]}
<Tooltip title={tooltipText[key]}>
<Button type="link" icon={<InfoCircleOutlined />} />
</Tooltip>
</Flex>
}
required
rules={[
{
required: true,
message: t('data.explorer.ValueRequired'),
},
]}
name={key}
key={key}
>
<InputNumber
min={optionRange[key].min}
max={optionRange[key].max}
style={{
width: '100%',
}}
/>
</Form.Item>
Copy link
Member

Choose a reason for hiding this comment

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

It doesn't seem necessary to manage networkOptions as a separate array and use the map function to create the UI. It looks like you did this considering the possibility of adding more options in the future. However, currently, there's only one option, and there's no guarantee that future additions will follow the same rule or use InputNumber.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I agree. I will modify everything that was managed as an array. Thank you! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:i18n Localization area:ux UI / UX issue. size:XL 500~ LoC
Projects
None yet
Development

Successfully merging this pull request may close these issues.

NEO configurations page using Setting List
4 participants