Skip to content

Add support for expressions within template literals - #61

Closed
giuseppeg wants to merge 9 commits into
vercel:masterfrom
giuseppeg:expressions
Closed

Add support for expressions within template literals#61
giuseppeg wants to merge 9 commits into
vercel:masterfrom
giuseppeg:expressions

Conversation

@giuseppeg

Copy link
Copy Markdown
Contributor

Fixes #25

@giuseppeg

giuseppeg commented Dec 29, 2016

Copy link
Copy Markdown
Contributor Author

fyi this patch doesn't allow expressions in the selector name like .col-${xsmall} not sure if that's necessary or that useful.

edit: actually it could be useful to define media queries and whatnot. That will require some work on the CSS compiler.

@sarukuku

Copy link
Copy Markdown

Waiting for this to land. 🚀

@giuseppeg

Copy link
Copy Markdown
Contributor Author

@rauchg, @nkzawa I think that this branch is ready for review.
Let me know if you need context but hopefully this solution makes sense and it is not too dumb :)

Comment thread src/babel.js Outdated
@@ -17,23 +18,98 @@ const STYLE_COMPONENT_CSS = 'css'
export default function ({types: t}) {
const findStyles = children => (
children.filter(el => (

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Just a small thing, think you can destructure this param ({node}) => ( which allows you to remove el in front of node

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

oh right good catch!

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🔥

@rauchg

rauchg commented Dec 30, 2016

Copy link
Copy Markdown
Member

Are we erroring upon usage of vars from the closure?

@giuseppeg

Copy link
Copy Markdown
Contributor Author

No but we could although it might add some overhead or be not that straightforward if we keep allowing things like call expressions

@giuseppeg

Copy link
Copy Markdown
Contributor Author

basically you want to make sure that people don't use props right?

@rauchg

rauchg commented Dec 31, 2016

Copy link
Copy Markdown
Member

Correct. If this doesn't fail it will create extremely difficult-to-understand bugs to the uninitiated:

export default ({ some, props }) => (
  <div>
    <style jsx>{`
      div { color: ${some} }
    `}</style>
  </div>
)

@giuseppeg

Copy link
Copy Markdown
Contributor Author

@rauchg any identifier in the scope or just props?

export default () => {
  const some = 'red' // allowed or not?

  return (<div>
    <style jsx>{`
      div { color: ${some} }
    `}</style>
  </div>)
}

@rauchg

rauchg commented Jan 1, 2017

Copy link
Copy Markdown
Member

I'd block anything from the scope. After all, if it's a constant, you should probably syntactically move it outside the scope…

Comment thread src/babel.js Outdated
if (isTemplateLiteral) {
// build the expression from transformedCss
traverse(
parse(`\`${transformedCss}\``).ast,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I think we should use https://github.com/babel/babylon

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

babel-core's transform uses babylon behind the wood

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

yep, but I meant it would be better to use the parser anyway.

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Behind the wood 😄👍

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

rofl typo. @nkzawa yea sorry I was rushing. In fact I thought of doing that initially but then I didn't feel like adding the extra dependency but if you think that it is preferable I have no problem with that.

@rauchg

rauchg commented Jan 6, 2017

Copy link
Copy Markdown
Member

Needs rebase

@giuseppeg

Copy link
Copy Markdown
Contributor Author

@rauchg you got it

@sarukuku

sarukuku commented Jan 16, 2017

Copy link
Copy Markdown

Any updates on this? Waiting to 🚀

@giuseppeg

Copy link
Copy Markdown
Contributor Author

@sarukuku I haven't had a lot of free time recently. Anyway we want to benchmark this before merging – I will try to push a minimal benchmark today after work.

@giuseppeg

Copy link
Copy Markdown
Contributor Author

301 to #80 :)

@giuseppeg giuseppeg closed this Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants