Skip to content
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

Merged
merged 2 commits into from Jan 31, 2020
Merged

Enhance toHaveStyle to accept JS as css #196

merged 2 commits into from Jan 31, 2020

Conversation

lourenci
Copy link
Contributor

@lourenci lourenci commented Jan 29, 2020

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.

  • Documentation
  • Tests
  • Updated Type Definitions
  • Ready to be merged

@codecov
Copy link

codecov bot commented Jan 29, 2020

Codecov Report

Merging #196 into master will not change coverage by %.
The diff coverage is n/a.

Impacted file tree graph

@@            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.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3b3a3d3...963646f. Read the comment docs.

Copy link
Member

@gnapse gnapse left a 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!

src/__tests__/to-have-style.js Show resolved Hide resolved
src/to-have-style.js Outdated Show resolved Hide resolved
@lourenci
Copy link
Contributor Author

I think it's ok to be reviewed and merged. I've never updated the types definitions on DefinitelyTyped, how can I do that? :)

@lourenci lourenci marked this pull request as ready for review January 31, 2020 00:04
Copy link
Member

@kentcdodds kentcdodds left a 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 👍

Comment on lines +195 to +199
function parseJStoCSS(document, css) {
const sandboxElement = document.createElement('div')
Object.assign(sandboxElement.style, css)
return sandboxElement.style.cssText
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is brilliant 👏

@gnapse
Copy link
Member

gnapse commented Jan 31, 2020

I've never updated the types definitions on DefinitelyTyped, how can I do that? :)

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?

Copy link
Member

@gnapse gnapse left a 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 &&
Copy link
Member

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:

Suggested change
!!Object.keys(styles).length &&
Object.keys(styles).length > 0 &&

Copy link
Contributor Author

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.

@kentcdodds
Copy link
Member

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 🤷‍♂️

@jgoz
Copy link
Collaborator

jgoz commented Jan 31, 2020

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?

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 npm install, npm test before you push, and you're good to go.

@gnapse
Copy link
Member

gnapse commented Jan 31, 2020

Ok, I'm merging this then. Still a bit unsettled that we lost co-location 🤷‍♂️

@gnapse gnapse merged commit 7921e4a into testing-library:master Jan 31, 2020
@gnapse
Copy link
Member

gnapse commented Jan 31, 2020

🎉 This PR is included in version 5.1.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

@lourenci
Copy link
Contributor Author

@jgoz I've just opened the PR there to update the types. DefinitelyTyped/DefinitelyTyped#42022

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

toHaveStyle support passing an object
4 participants