-
Notifications
You must be signed in to change notification settings - Fork 76
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
chore: add runtime component deprecation warnings #9821
Conversation
|
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.
This will be awesome! 💯
import { CSS, SLOTS } from "./resources"; | ||
|
||
logger.deprecated("component", { |
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.
this is super cool!
} | ||
|
||
const badgeTemplate = "%ccalcite"; | ||
const badgeStyle = "background: #007AC2; color: #fff; border-radius: 4px;padding: 2px 4px;"; |
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.
Should design approve the styling :)
Wondering if we could use CSS vars here instead of styles. I guess it doesn't really matter since its just a log badge but still.
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 did test this, but no dice. Custom CSS props don't appear to be available for console styling. 😞
listFormatter = new Intl.ListFormat("en", { style: "long", type: "disjunction" }); | ||
} | ||
|
||
const message = `[${name}] ${context} is deprecated and will be removed in ${removalVersion === "future" ? `a future version` : `v${removalVersion}`}.${suggested ? ` Use ${multiSuggestions ? listFormatter.format(suggested.map((suggestion) => `"${suggestion}"`)) : `"${suggested}"`} instead.` : ""}`; |
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.
We don't need to translate this right?
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.
Correct. Dev messaging is not translated.
This is great! 💪 👏 I'm with Matt on points 1, 2, and 3 from his first comment above. |
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.
Awesome!! 💪🏻
As far as the version, should we also mention a timeframe for folks to plan, or keep it vague with the version? Something like:
calcite
[tip-group] component is deprecated and will be removed in v4 (2025 Q4). Use "carousel" or "carousel item" instead.
- Badge 👍👎?
Badge it up! 🦡📛
- Assuming 👍 on the badge, should we keep calcite in component names used in messaging? The badge already provides context
For consistency with our documentation, its okay to omit since its mentioned already in the badge. If we remove the badge, we should leave it in though.
The only hesitation would be if omitting it creates confusion for developers to use the recommended component(s).
It looks like the messaging also adds "
to the recommended components, should the symbol be around each of the recommendations, like:
Use "carousel" or "carousel-item" instead.
- Do we want to keep logLevel in the config or should we do something similar to Maps SDK's config for future log-related features? I don't see a use case for interceptors at the moment.
Flexible on whichever approach is best as long as it is clear to developers working with both Maps SDK and Calcite.
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 idea as well! One suggestion that hasn't been mentioned, maybe add a "none" or "disabled" option to logLevels
? That way teams can completely turn it off in prod and set it to something verbose in dev.
I like the idea of adding the timeframe, but this would be tricky to maintain and enforce via TypeScript.
I hear ya. We should be good on this front since we do have the badge giving context and often omit
My bad. 😅 I used an outdated screenshot. Each component should be quoted in the latest version (covered by a test too). |
Thanks for the feedback, y'all! 🚀 Made the following changes:
|
+1 for badge, +1 for keeping |
…-to-monorepo * origin/dev: chore: release next fix(tabs): handle tab close events that remove the associated tab-title and tab elements from the DOM (#9768) chore: add runtime component deprecation warnings (#9821) build(deps): drop unnecessary @types/prettier dep (#9833) build: update browserslist db (#9822) build(deps): update dependency dayjs to v1.11.12 (#9824) build(deps): update dependency semver to v7.6.3 (#9825)
Related Issue: #9295
Summary
This adds deprecation warning messages to components marked for deprecation at v3 and v4.
Notes
logLevel
to the config for users to specify a different log levelQuestions
calcite
in component names used in messaging? The badge already provides contextlogLevel
in the config or should we do something similar to Maps SDK's config for future log-related features? I don't see a use case forinterceptors
at the moment.