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
Enhance toHaveStyle to accept JS as css #196
Enhance toHaveStyle to accept JS as css #196
Conversation
Codecov Report
@@ Coverage Diff @@
## master #196 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 19 19
Lines 235 240 +5
Branches 57 58 +1
=========================================
+ Hits 235 240 +5 Continue to review full report at Codecov.
|
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 know this is not yet marked as ready for review, but wanted to share that looks good, and it seems to be simpler to achieve than I imagined 😀
Thanks!
I think it's ok to be reviewed and merged. I've never updated the types definitions on DefinitelyTyped, how can I do 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.
Looks good to me 👍
function parseJStoCSS(document, css) { | ||
const sandboxElement = document.createElement('div') | ||
Object.assign(sandboxElement.style, css) | ||
return sandboxElement.style.cssText | ||
} |
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 brilliant 👏
Good question. This was my fear when we switched to that instead of providing the types ourselves. Seems to go against co-location 😀 @jgoz @kentcdodds any experience with that? Any advice on how to proceed? |
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 good.
Just one suggestion, and also, let's wait to see what about the type definitions.
([prop, value]) => | ||
computedStyle.getPropertyValue(prop.toLowerCase()) === value, | ||
return ( | ||
!!Object.keys(styles).length && |
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 guess you added this because we now need to return false
if the object is empty, right?
Also, why not the more explicit alternative:
!!Object.keys(styles).length && | |
Object.keys(styles).length > 0 && |
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 guess you added this because we now need to return
false
if the object is empty, right?
Yes.
On the types, I pretty much just merge the PRs that make code changes whenever they're ready to be merged. Then eventually someone makes a PR to update DefinitelyTyped. Sometimes that happens before the merge, other times it happens after. In any case it happens eventually and it's fine 🤷♂️ |
It's fairly straightforward. Fork the DT repo, make the change, open a PR. Their process is really streamlined for new PRs. The bot would likely ping me for a review since I'm the "author" of the typings and once I approve, a DT maintainer would merge it pretty quickly. It can be a bit daunting because the DT repo is so huge, but it's just like any other npm package. Run |
Ok, I'm merging this then. Still a bit unsettled that we lost co-location 🤷♂️ |
🎉 This PR is included in version 5.1.0 🎉 The release is available on:
Your semantic-release bot 📦🚀 |
@jgoz I've just opened the PR there to update the types. DefinitelyTyped/DefinitelyTyped#42022 |
This is a first naive implementation to resolve #179 .
I don't know the best way to generate a css text from an object, so I'm underlying to the DOM to do that.