Skip to content

fix(site): disable auto fields when they are disabled in the template settings #10022

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

Merged
merged 4 commits into from
Oct 4, 2023

Conversation

BrunoQuaresma
Copy link
Collaborator

@BrunoQuaresma BrunoQuaresma commented Oct 3, 2023

  • Disable form inputs
  • Add disable badge + tooltip with more info
Screen Shot 2023-10-03 at 14 20 26

Fix #9820

@BrunoQuaresma BrunoQuaresma requested a review from a team October 3, 2023 17:21
@BrunoQuaresma BrunoQuaresma self-assigned this Oct 3, 2023
@BrunoQuaresma BrunoQuaresma requested review from Parkreiner and removed request for a team October 3, 2023 17:21
@BrunoQuaresma BrunoQuaresma changed the title fix(site): disable auto-stop and auto-start fields when they are disabled in the template settings fix(site): disable auto fields when they are disabled in the template settings Oct 3, 2023
Copy link
Member

@code-asher code-asher left a comment

Choose a reason for hiding this comment

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

Looks good! One thing I noticed is that if you already had auto-start/stop set up and then they are disabled via the template, you can still change the time/day/hour fields and you can still hit Submit but nothing actually updates. Should we disable those fields as well?

& > svg {
return (
<div
ref={ref}
Copy link
Member

Choose a reason for hiding this comment

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

I am probably missing something obvious, but what does passing in ref here do?

Copy link
Member

@Parkreiner Parkreiner Oct 4, 2023

Choose a reason for hiding this comment

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

The ref gives any parent component the ability to manipulate the the div element created by Pill.

So for example:

function Parent () {
  const divRef = useRef<HTMLDivElement>(null);
  return <Pill ref={divRef} {...otherProps} />
}

With this setup, the parent would be able to manipulate the real HTML div element that Pill creates from inside useEffect and event handlers, even though the div exists in a separate component

Copy link
Member

Choose a reason for hiding this comment

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

But judging from this PR, I think it's a preemptive change to make the component more reusable. I don't see any of the <Pill /> instances in the rest of the code using it

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes, it is used by the Tooltip component that wraps the Pill

Copy link
Member

Choose a reason for hiding this comment

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

Ohhhhh I see. I see it in the docs. Unfortunate that it is not reflected in the code! I guess you just have to know how MUI tooltip works. Thanks for the explanations!

@code-asher
Copy link
Member

Whoops lol I misread my GitHub notifications and just noticed this was assigned to someone else, I will remove the assignment since I already reviewed haha. Sorry all.

@code-asher code-asher removed the request for review from Parkreiner October 4, 2023 16:57
Copy link
Member

@Parkreiner Parkreiner left a comment

Choose a reason for hiding this comment

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

Looks good! Mainly commenting to reply to Asher

}
return themeStyles(type, lightBorder);
}, [type, lightBorder]);
const typeStyles = useMemo(() => {
Copy link
Member

Choose a reason for hiding this comment

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

Does this need to be memoized? I guess it just feels like the logic wouldn't have much overhead, and it's only being used within the same component

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I don't think so, I guess it is only using memo as a way to wrap/encapsulate it into a function but I'm just guessing.

& > svg {
return (
<div
ref={ref}
Copy link
Member

@Parkreiner Parkreiner Oct 4, 2023

Choose a reason for hiding this comment

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

The ref gives any parent component the ability to manipulate the the div element created by Pill.

So for example:

function Parent () {
  const divRef = useRef<HTMLDivElement>(null);
  return <Pill ref={divRef} {...otherProps} />
}

With this setup, the parent would be able to manipulate the real HTML div element that Pill creates from inside useEffect and event handlers, even though the div exists in a separate component

& > svg {
return (
<div
ref={ref}
Copy link
Member

Choose a reason for hiding this comment

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

But judging from this PR, I think it's a preemptive change to make the component more reusable. I don't see any of the <Pill /> instances in the rest of the code using it

@BrunoQuaresma BrunoQuaresma merged commit 516b88d into main Oct 4, 2023
@BrunoQuaresma BrunoQuaresma deleted the bq/fix-auto-stop-showing-when-not branch October 4, 2023 18:00
@github-actions github-actions bot locked and limited conversation to collaborators Oct 4, 2023
@code-asher
Copy link
Member

Just reposting this because I did not see a reply to it:

One thing I noticed is that if you already had auto-start/stop set up and then they are disabled via the template, you can still change the time/day/hour fields and you can still hit Submit but nothing actually updates. Should we disable those fields as well?

@BrunoQuaresma
Copy link
Collaborator Author

@code-asher I missed this comment, sorry! I think what you suggest is the right move. I will fix it.

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

Successfully merging this pull request may close these issues.

bug: disabling auto-start still lets the user think they can set auto-start
3 participants