Closed kb1995 closed 2 years ago
That's odd. It sounds like the component keys are causing ordering issues when the preview data replaces the static data.
I'll investigate and get back to you.
Since you are using Gatsby (correct me if I'm wrong), you have access to an id
field for each Slice. This is Gatsby-specific, but with that, we could add a prop that lets you use that ID as the Slice's component key. We would still need to find a way to support non-Gatsby usage, however.
@angeloashmore Yes, I think that will be a nice solution for this. We need to make sure to mention in the docs that it's advisable to query the ID as part of the graphql query. Myself I usually just query slice_label and slice_type and often omit the ID.
I just had a look at the source code. The way that you generate the slice is using const key = JSON.stringify(slice);
This means that if I have 2 slices with the exact same data and I don't query the ID, then they would have the same key. For example, a simple Spacing slice. I assume the problem would be solved if we include ID in all of our Slice queries.
A potential solution would be to create the key logic using slice-${slice.slice_type}-${index}
-> this is the logic I'm currently using for my custom SliceZone and it's been working quite well for me.
@kb1995 Could you try v2.0.0-beta.7
and let me know if that fixes your issue?
I was able to reproduce the same issue. To fix it, I prepended the Slice's index to the key and kept JSON.stringify
, similar to what you suggested. Using the full object in the key makes sure Slices with the same type and index won't have the same key.
(Imagine, for example, you have two Slices with the same type but different content in the fields. If we didn't account for the content fields, the components may not be correctly identified since the keys could overlap.)
I think using this strategy should work for all cases. I did not expose a getKey
prop that lets you give a function since that could cause confusion for some users. If we come across this issue again, however, then adding an explicit prop to define your own key may be required.
@angeloashmore I finally came around upgrading the package and from the looks of it, the bug is fixed. Thanks!
I agree - even my case is already an edge case, so I doubt this will be a common case.
Awesome, thanks for testing it out! I'll keep this issue in mind as others start to try out the updated library.
Versions
When not in Preview, the content is rendered correctly in the correct order. However, when in preview, there are couple of Slices which shouldn't be on the top, appearing on the top.
My SliceZone Resolve
console.log(slices)
renders the content in the correct order, however they don't appear in the same order in the browserI'm getting several warnings in the console.