avoid links and buttons being able to be switched#65
Conversation
|
✔️ Deploy Preview for stackbit-components ready! 🔨 Explore the source changes: cd4a766 🔍 Inspect the deploy log: https://app.netlify.com/sites/stackbit-components/deploys/6197f8ae001e900007f99640 😎 Browse the preview: https://deploy-preview-65--stackbit-components.netlify.app |
| @@ -57,10 +57,6 @@ fields: | |||
| options: | |||
There was a problem hiding this comment.
if link cannot be changed, maybe it is better to remove this field altogether?
There was a problem hiding this comment.
@ScottyMJacobson said he'll take care of cleaning it up :)
There was a problem hiding this comment.
@smnh how concerned are we about backwards-compatibility right now? will projects that have a Link with this style field break or just print an error?
either way, let's def make sure to update templates when we link it against this version of stackbit-components so that Links don't have these fields anymore, and if there are Buttons with style Link hanging around, let's make them Links (and vice versa)
There was a problem hiding this comment.
@ScottyMJacobson I tested this in Studio and style field was removed.
It seems like to release this safely the following things still need to be done.
- Can you please check the component itself and add the proper guards to link and button if the style prop is missing?
- Can you also update any content in
stackbit-content-packsand remove the style field.
There was a problem hiding this comment.
Thanks @JugglerX!
Can you please check the component itself and add the proper guards to link and button if the style prop is missing?
They share a common <Action /> component implementation, so I think they're both already safe if style is missing (falls back to default)
Can you also update any content in stackbit-content-packs and remove the style field.
Ah! that was the piece I was missing. I'll go do that
5 participants
No description provided.