pharos
pharos copied to clipboard
Button: Update on-background attribute for ease of use in Vue 3
Expected behavior
When on-background
attribute is applied to the button, the color scheme of the button is properly reflected
Actual behavior
on-background
attribute is removed from the DOM, likely by Vue 3, possibly because it starts with on*
and Vue 3 interprets that to be an event listener.
Steps to reproduce the issue
- Create pharos button with
on-background
set on the element - Load up the app and see that the
on-background
is removed from the DOM - Button does not appear as we would expect
Screenshots or code I tried making a codepen/codesandbox/stackblitz but each environment was having various issues. I'll keep trying to get a working example.
https://user-images.githubusercontent.com/13315416/153255838-d599f486-0e0d-4917-afa8-1e81b7e44038.mov
Pharos version 11.2.1
Your environment
- OS: macOS
- Browser: Chrome, Safari, Firefox
- Version: 98, 15.3, 92.0
Additional information I couldn't find anything in the Vue3 docs where this was happening but the button works perfectly well in the same code on a Vue2 app.
@michael-iden To avoid a breaking change, you can probably use <pharos-button .onBackground="true">hi</pharos-button>
instead to set the attribute via the prop. Some reading here on that.
@Niznikr It works! Thanks for the great suggestion!
@michael-iden is a fix still needed for this?
@chrisjbrown I think we still want to fix this and include #308 in the next set of breaking changes. Looks like Dane already tagged issue/PR with the v13 milestone and I can make sure it gets included
FWIW-- Using Nuxt 3 I couldn't get it working with .onBackground
but instead with this: :on-background.attr
@michael-iden is this issue still reproducible or are we able to close it now? I'm not too familiar with Vue to test it locally 😅
@mtorres3 I think this is still technically an issue until pharos 14 is released. Its handled by the PR you merged here https://github.com/ithaka/pharos/pull/578 but i don't know if we are closing issues as we merge the relevant PRs or close issues once the feature is publicly available in the main release channel.
@daneah did you have any preference on how we manage issues where the work its done and we are in a holding pattern for the release?
@michael-iden I much prefer to close issues as a fix for them is merged, regardless of whether that fix has yet been released—it becomes difficult to do bookkeeping otherwise.