-
Notifications
You must be signed in to change notification settings - Fork 6
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
Update button to Polaris v3.10.0 #291
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.
Oh crazy Andy 😛 Looks good, just had a comment on some template stuffs.
`href` attribute instead of replacing the whole element. | ||
--}} | ||
<a id={{id}} class={{classes}} aria-label={{accessibilityLabel}} data-test-id={{dataTestId}}> | ||
{{#if hasBlock}} |
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.
Does
{{#component contentComponent}}
{{yield}}
{{/component contentComponent}}
do the same thing as
{{component contentComponent}}
if there isn't a block to yield? If so maybe we don't need the hasBlock
check.
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'd imagine most of the time, yes, but if contentComponent
has different behaviour depending on whether it's in block or inline mode then we need to render it in either block or inline mode as appropriate. This is the case with quite a number of the components in ember-polaris
, which yield if they're used in block mode, or render their text
attribute otherwise.
I made a twiddle to show what I mean: both instance of outer-component
cause inner-component
to be rendered in inline mode - even if outer-component
is rendered in block mode. It's a nuisance as your suggested simplification would be very nice, but unfortunately has breaking behaviour (which IIRC we've hit in the early days of ember-polaris
) 😞
Will wait for @vladucu's 👀 on this before merging cos this is a big and potentially breaking refactor 😅 |
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.
looks pretty good to me!
{{#if url}} | ||
{{#if isDisabled}} | ||
{{!-- | ||
Render an `<a>` so toggling disabled/enabled state changes only the |
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.
is this really a problem in Ember...or is it more to keep implementation as close as possible?
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.
The latter - I don't see any real disadvantage to having this implemented and it makes sure we're matching the React implementation closely, which can't hurt 🤷♂️
await render(hbs`{{polaris-button url=mockUrl}}`); | ||
assert | ||
.dom('a[data-polaris-unstyled]') | ||
.hasAttribute('href', this.get('mockUrl')); |
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.
no biggie (or need to update), but we should really start to use ES6 getters
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.
Do ES6 getters work with older versions of Ember (e.g. 2.18, which we still support)? Or do they cause any potential issues with apps that use older versions of Ember?
assert.dom('button').hasText(this.get('label')); | ||
}); | ||
|
||
test('renders the given children into the link', async function(assert) { |
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.
children
is really react-world.... 😜
block-form
?
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 think we all know what this means, and matching the React code makes the upgrade process much clearer (as I'm finding out this time around 😬)
Adds
monochrome
,download
andisPressed
properties topolaris-button
. Also, to make future updates easier, I've rewrittenpolaris-button
from scratch as a more-or-less direct port of the React implementation 🤷♂️ This will need careful and thorough testing in our apps to ensure the rewrite hasn't broken anything, although all our oldpolaris-button
tests still passed before I replaced them with the React tests.