Remove the experimental PreviewOptions component from the block-editor package #30906
Conversation
youknowriad
added
[Type] Enhancement
|
Size Change: -524 B (0%) Total Size: 1.39 MB
ℹ️ View Unchanged
|
|
First of all, +1 on changing the button label :D As for adding the Template item here, I am torn. The flow feels somewhat problematic to me because it suggests I am still editing the post while viewing the template. While that is representative of what happens on the canvas, it does not reflect what is happening behind the scenes – I'm now editing the template while viewing the content. It's a subtle but significant change and I'm not 100% convinced that the View menu is the appropriate location for this pathway. Does it blur the lines too much? My feeling is that there are perhaps bigger questions to be answered around the flows enabling users to traverse template / content editing, contextual block locking, and so on, before giving this the green light. Then again, maybe this is ok to merge for now, and we can refine things along the way as those questions are answered. Like I said before, I am torn. |
|
Before:
After:
The Template feature:
On the template switch, will this be the only or primary way to toggle between template and post content only view? I had pictured it sitting in a top-center dropdown. In relation to that, and on the change to just "View", I increasingly feel it can make sense. But probably we should only do it if we're pretty confident that this View menu is the long-term home for the template editor switch. About the "Back" button. It feels misleading that it sits there, pointing directionally to the left, when the effect is more of a toggle. Do we need to do the top-center dropdown and have the breadcrumb-style back sit there? If the blocker for the top-center dropdown is the "Top Toolbar" option, I have a solution for that in #30234 (comment), even if I'll need a little help to land it. |
yes we need to land your PR first but it's not really the blocker for me. I just think both make sense :P -- |
Actually I was thinking it might be slightly early to rename to view, and that it'd feel more appropriate when there's a bigger need for it. I guess it depends a bit on where we go with the canonical location for how to start editing the template. I'm not convinced it's this menu, even if in an older mockup I have seen something like the Code editor / Visual editor switch we have in the top toolbar more menu. Something like, but with better labels: |
|
@jasmussen I think you just touched upon why I am torn on this PR in its current format. I've said this before, and still believe it to be true: there is value in being able to view the template while editing a post, and having access to that via the View menu makes perfect sense to me. But in that particular flow I should not be able to manipulate the template in any way. The primary tab in the inspector would remain "Post", the top bar would not state "Editing: Template name", the template blocks on the canvas would be locked and serve only as a (one of several) pathway to template editing. |
|
Ok I'm fine post postponing any work here, just let me know what's the best approach for you. That said, I still want to land some good bits of refactoring included in this PR even if we don't change the behavior at all. |
I hear what you're saying here, but if we have both the ability to view (only view not edit) the template while writing, and actually edit, there needs to also be a visual differentiation so you know whether something is editable or not. For that reason, I think any view-only features should probably be separate, and come after, any actual editing changes which is what Riad is iterating here. So I'm hearing we need the top center dropdown for those bits? |
That is where something like the click-through pattern comes in to play.
Yes, I think so. All the pieces are closely related though, since we'll need to enable fluid movement between editing content + viewing template, to editing template + viewing content. FWIW this is (roughly) what I have in mind as an option for viewing a template while editing a post, and in that flow moving to editing template + viewing content via click-through, and then back to the beginning: view.template.mp4The biggest missing piece there seems to be the locking of template blocks while editing a post, and clicking through to edit the template. Edit: Oh, and consensus around whether the idea of viewing the template while editing the content is worthwhile :D |
|
Ah, so view template literally shows it, but edit template both shows it but also adds the frame. Right at this point in time, I'm not sure that distinction is clear or valuable enough. But it's good to have the avenue explored, and it will likely become clearer as we get closer to that goal. |
|
Yes I think I agree. In that case we should concentrate on adding the top menu in the post editor and working out how one accesses the template editor from there, as you said before :D |
|
Ok so I restored the behavior to match trunk. This is basically just a "refactoring PR", since this work is done and will allows us tweaks to this menu in the future, we might as well just merge it. |
youknowriad
changed the title
youknowriad
added
[Type] Code Quality
youknowriad
force-pushed
the
add/template-to-view-menu
branch
from
f49d7af to
98bd12e
Compare
|
Closing as it's a bit outdated now. |
This PR adds a "template" link to the "Preview" menu and rename the menu to just "View".(After discussions this part has been reverted)While doing this, I also thought adding a link to the actual published posts, something like "View live in the frontend" would be good, we had a request for a link like that for some time as it's not very highlighted at the moment in the UI. WDYT
Another thing in this PR is a small refactor to remove a reusable "PreviewOptions" component that was present in the "block-editor" package to be reused in both edit-post and edit-site but the reality is that this component doesn't make sense there.