-
Notifications
You must be signed in to change notification settings - Fork 14
"Missing 'key' prop for element in iterator" with metal.js #16
Comments
Thanks for filing the issue Bryce. I've been thinking this over for a while since the port over to metal, so my initial idea was to allow that to be defined with a custom rule, such as:
But are you saying you guys need to support both? Meaning, should it look for the existence of any "key" attribute, or do you only need to support one? |
We would need to support both, and if possible warn of each unique instance. If possible the warnings would emit for // For component
array.map(
(item, i) => (
// no warning
<MetalComponent ref={i} />
// warn that key is being passed instead of ref
<MetalComponent key={i} />
// warn that no ref is being passes
<MetalComponent />
)
)
// For element
array.map(
(item, i) => (
// no warning
<div key={i} />
// warn here that ref is being used instead of key
<div ref={i} />
// warn here that key is not being passed
<div />
)
) let me know if that makes sense |
Hmm... okay, I think I'm a bit confused. Couldn't both attributes be passed to both elements and components at the same time? Also, are I'm thinking if they're used for the exact same thing on elements and components, I would imagine they should be named the same thing. The reason I'm asking is because I can create the rule to do what you're saying, but I would prefer that the metal API was more consistent in this regard. What do you think? |
The difference is that a <ParentComponent>
<Child ref="childComponent" />
</ParentComponent> ParentComponent can now access the child via However, a static html element such as a Refs are also used to track the internal components when they are conditionally rendered with different state. <ParentComponent>
<Child name="foo" ref="child1" />
{someBool &&
<Child name="bar" ref="child2" />
}
<Child name="baz" ref="child3" />
</ParentComponent> When using refs keep track of component state, whereas a key is just for ordering. When adding a ref to a component, a key is internally provided as I think the overall purpose of a Let me know if that makes a little more sense. |
After writing this issue out and going back to tinker with keys and refs a bit. I am sort of in the same boat as you, kind of confused on the API. So I created an issue to discuss it on metal. metal/metal.js#129 We can figure out the formatting issue after that discussion is fleshed out. |
Heya Bryce, Please reopen or open a new one if we still need to work out the details of this one. Thanks Bryce, |
Hey Nate, Metal doesn't require keys or refs for components in an array. It's "supposed" (there were some bugs where it wasn't that are now fixed) to handle that case behind the scenes. Source formatter shouldn't be flagging 'Missing "key" prop for element in array" when using metal. |
In Metal.js we use "refs" for components when iterating through rather than a key. The linter should check for either ref or key for metal.js comonents. Metal will internally set key to ref for components.
The text was updated successfully, but these errors were encountered: