Bug fix — faulty title collision caused by autosave

[mike-day]

Currently, there is a tricky little bug involving autosave that is annoying to recreate 😆

Lets say that you rename a pattern but do not click save, opting instead to change other meta values. But then you change your mind about renaming the pattern, deciding instead to stick with the title you already had.

Upon retyping the old pattern title, if autosave has saved your work, the initial title will improperly error as a name collision.

This PR corrects that by getting the currentName (equivalent to the slug) from getCurrentPostAttribute for checking against the title. Using this method avoids needing to use a ref, but works in a similar way.

---

How to test

1. Checkout the branch
2. Open a pattern
3. Rename the pattern, but do not click Update Pattern
4. Wait for an autosave
5. Type the old pattern name — there should be no collision

[mike-day]

This is a new hook that I think could make sense to keep. The saved data is inherently different from the edited data since we are editing data directly (via editPost for example) as values change.

The saved and edited data won't necessarily match until the post is actually saved.

[kienstra]

Looks good so far. It keeps the same level of abstraction as useEditedPostData()

[mike-day]

Passing in currentName here behaves somewhat like a ref for our purposes.

[mike-day]

This is no longer needed — the new hook uses this call to get currentName.

[kienstra]

Yes!!

[mike-day]

postMeta is still passed to TitlePanel to satisfy typing, but it is no longer used in the component.

I think we should consider rethinking the passing of postMeta to every component, instead getting the values we need from useEditedPostData and passing them directly as props.

For example, instead of this:

<KeywordsPanel
    postMeta={ postMeta }
    handleChange={ updatePostMeta }
/>
<DescriptionPanel
    postMeta={ postMeta }
    handleChange={ updatePostMeta }
/>

...we could do something like this:

<KeywordsPanel
    keywords={ metaKeywords }
    handleChange={ updatePostMeta }
/>
<DescriptionPanel
    description={ metaDescription }
    handleChange={ updatePostMeta }
/>

---

Or we could also use context instead of passing these props around.

[kienstra]

Interesting! I'll look at this later today if that's alright.

[mike-day]

Interesting! I'll look at this later today if that's alright.

Of course! No rush on this one — I only noticed from running my demo a bunch of times.

[kienstra]

Hi @mike-day,
Really nice fix. With your 'How to test' steps, there's no title collision message anymore:

[kienstra]

I think we should consider rethinking the passing of postMeta to every component, instead getting the values we need from useEditedPostData and passing them directly as props.

Good idea. The components should only accept the meta value they need, not all of postMeta.

I'd say it's fine to keep passing them as props, instead of putting them in global context.

[mike-day]

@kienstra please check me on this, but I also noticed that we don't seem to use title from postMeta anymore — we are getting the actual post title, so that meta property is not needed.

I went ahead and removed that property as well with 0d46e71.

[mike-day]

I think we should consider rethinking the passing of postMeta to every component, instead getting the values we need from useEditedPostData and passing them directly as props.

Good idea. The components should only accept the meta value they need, not all of postMeta.

I'd say it's fine to keep passing them as props, instead putting them in global context.

Cool, I think it will be a bit cleaner that way! I am going to complete that work in a new PR after merging this one.

[kienstra]

@kienstra please check me on this, but I also noticed that we don't seem to use title from postMeta anymore — we are getting the actual post title, so that meta property is not needed.

That's right, good catch.

[kienstra]

Nice one, I wouldn't have thought of that