Issues with props rest spread operator

[bcarroll22]

Hey Vue team,

Very nice work on everything with 2.0. So far, it's been awesome to use!

I just tried to use the spread operator with props, and I'm getting an error. I've verified that the spread operator is working correctly in other places, and I've also verified that the props are being passed in correctly.

Here's the error that I am getting:

Thanks again for the great work with 2.0!

[bcarroll22]

I also just verified that the spread operator works when manually building the hypertext function:

h(Grandchild, {
  props: {
    ...props
  }
})

I did a little digging, and it looks like when using the spread operator, the attribs that get passed into buildOpeningElementAttributes is undefined.

[bcarroll22]

Actually, testing even further up the chain, it looks like I can try to console.log(path) in the JSXElement property of the export return, and for the component with the spread operator the path is undefined. For reference, I'm just doing <Grandchild {...props} />

[yyx990803]

JSX spread puts all properties in the spread object as top-level properties, so they are not nested under props. You will need to do <Grandchild {...{ props }} /> to ensure it's nested.

We may do some more exploration on how spread should work for Vue's vnode format though, since this seems to going be a common gotcha.

[bcarroll22]

I see, isn't spreading at the top level still valid with Vue though? How does the jsx parser handle me putting the props at the top level? What I mean is, this works:

<Child test={'hello'} otherTest={'world'} />

This doesn't

<Child {...props} />

But wouldn't they produce the same output? Or does the parser somehow know to put test and otherTest in props?

[yyx990803]

The nesting is determined at syntax level but the spread is actually done
via a runtime extend helper, so they are different.
On Sun, Jun 19, 2016 at 9:47 AM Brandon Carroll notifications@github.com
wrote:

I see, isn't spreading at the top level still valid with Vue though? How
does the jsx parser handle me putting the props at the top level? What I
mean is, this works:

<Child test={'hello'} otherTest={'world'} />

This doesn't

<Child {...props} />

But wouldn't they produce the same output? Or does the parser somehow know
to put test and otherTest in props?

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAefXrnPFp1Yf6hcdn8DlgIJhP5X1ojBks5qNUiIgaJpZM4I5EIJ
.

[blocka]

I'm trying to do something like this

<Link to={somewhere} style={{color: 'red'}}>A link</link>

Where I want Link, a functional component, to render an a tag with the given attributes passed in.

I noticed that the style object is being passed in as data so I tried:

return <a href={to} {...data}>{children()}</a>

However, that throws out the href.

trying <a href={to} {...{ data }}>{children()}</a> the style attribute doesn't get through and

<a href={to} {...{ ...data }}>{children()}</a> gives me a syntax error.

[yyx990803]

1.1.0 now has improved JSX spread support - just spread it with {...data} and it will merge them properly.

[blocka]

Still having some issues

<Component {...props}></Component>

renders as

return h(
      'div',
      null,
      [h(
        Component,
        props,
        function () {
          return [];
        }
      )]

and <Component {...{ props }}></Component>

renders as

return h(
      'div',
      null,
      [h(
        Component,
        {
          attrs: { props: props }
        }

[yyx990803]

You need to spread to top-level data object, not props.

[blocka]

So how would I do this with props, exactly?

[yyx990803]

...{{ props }} my bad, {...{props}} should work, if not I'll try to fix it.

[blocka]

<Component ...{{ props }}></Component> gives me a syntax error.

[blocka]

For the record, this worked (basically what I see you've done in the test), although I'm not 100% happy with it (can't complain too much).

const data = {props};

return <Component {...data}></Component>

This did not though (props did not get passed through):

return <Component {...{props}}></Component>

[yyx990803]

@blocka indeed, fixed in 1.1.1