-
Notifications
You must be signed in to change notification settings - Fork 536
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
docs(adr): add development-warnings adr #2928
Conversation
|
size-limit report 📦
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this direction! Once this merges, could we create an issue to implement the warning()
helper?
should use the `warning()` helper. | ||
|
||
```ts | ||
warning(condition, 'This is the message that is logged when condition is false-y') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would have guessed that the message would display if the condition is truthy. I read that code as "warn if condition"
If this is a convention, I'm fine to keep it. But I wanted to mention my initial confusion.
If the name of the helper was something like assert()
, I think falsey would make more sense.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would have guessed that the message would display if the condition is truthy. I read that code as "warn if condition"
Ohh, this is how I think it was as well the entire time - now realised that 🙈
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Totally makes sense! Happy to flip it if that's more intuitive for folks 👍
I think the convention stems from invariant()
ultimately, and things like assert()
, that frame things from the perspective of "this condition must be met". When it's not met, throw an error, log a warning, etc
To contextualize the two, here is the warning from Heading
in the two styles:
// Warn if condition is true
warning(
innerRef.current && !(innerRef.current instanceof HTMLHeadingElement),
'This Heading component should be an instanceof of h1-h6'
);
// Warn if condition is false
warning(
innerRef.current && innerRef.current instanceof HTMLHeadingElement,
'This Heading component should be an instanceof of h1-h6'
);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks Josh! Warning when the condition truthy feels more intuitive to me. That said, it is totally cool to me if we want follow the convention that it stems from.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's do truth-y then! I'll update the ADR accordingly 👍
This comment was marked as outdated.
This comment was marked as outdated.
@joshblack so far it seems most folks are in alignment here, but if you'd like me to assign a decision-maker on this one give me a shout. |
ADR for Development Warnings in
@primer/react
Rendered markdown
Pull Request