Bootstrap the sections exploded view #40314
Conversation
youknowriad
added
[Type] Experimental
youknowriad
requested review from
mcsf,
mtias,
jameskoster,
jasmussen and
jorgefilipecosta
|
Size Change: +1.57 kB (0%) Total Size: 1.23 MB
ℹ️ View Unchanged
|
|
Even in this early state, the exploded view already offers a clear delineation between top level sections, big and convenient points for inserting sections, a distinct context for suggesting particular patterns (headers, sections, footers), a better overview of large page-sized patterns, and a mode that intrinsically could offer intuitive drag and drop. I think there's something to this.
Depends! I imagine it would be useful at the very least for page editing, especially in helping choose page templates, or page-size patterns. It seems prudent to start in the site editor.
I'm curious what others feel, but I'd think the animation to a crucial part of this. Are there any creative solutions we can think of? Instead of animating the iframe itself, could we animate just the contents? I understand there would likely be some challenges with background colors, collapsing margins and such, but those seem worth delving into on their own.
You mean floats here? I'd think that acceptable.
Agreed, there's enough overlap that it could potentially be the same, though I'd push any experiments to merge the two a bit in front of us still.
👌 — this would allow us to make the entire thing into a drag/drop'able unit, right?
At the moment there is a "focus" feature that lets you edit a template part in isolation. You click the template part, click "Edit" from the ellipsis menu, and you're editing that part in isolation, with dark clearance around it. To an extent, I'm thinking of this interface as the same as that — a "focused" view. Technical challenges aside (I'm sure they are legion), we could make this view contextual; select a group block and click the button, and it explodes just the blocks inside in an isolated view, just like isolated template part editing. These are vague ideas, to be clear, but it's all to say that if we can get this to a place that makes us happy for vertical themes, there are options we can explore other layouts as well. |
|
Exploring some icon options as an alternative to using the Stack icon, I don't really love any of these yet:
|
Perhaps there are some rules we can apply that determine whether or not this mode is enabled? One could be; If there are ≤1 root blocks in the current view, disable exploded view. That way – as Joen says – if you entered focus mode for the single root block, exploded view would become enabled. The challenge then is how to handle horizontal layouts, I think you mentioned to this in the OP. For example consider this structure:
If I enter focus mode for the root Row, then entered exploded view, it wouldn't work. So we'd probably also need a rule that says; If the container orientation is horizontal, then disable exploded view. |
|
I've been thinking about this PR, it's clear that we won't be able to implement the mode entirely in a single PR and since it's a new button and don't have any backward compatibility impact or whatsoever, I was thinking what would be the minimal accepted version for this to land to allow us to iterate on it quickly. I know the mode needs:
Am I missing anything here? Now, from that list I think the MVP could include the following and leave the rest for dedicated PRs.
What do you think? |
|
Would it be possible to also include some basic logic around when the mode is enabled or not? We should think about how to handle panels like Inserter / List view / Inspector in the mean time as well, the current disabled state feels a bit strange to me. It might be simpler to just force-close those panels when you enter exploded mode. Then if you click one in exploded mode, you just return to "normal" and the panel opens.
It would be neat to try this as well, but the original idea was that the toolbar(s) would appear on hover, and a single click on any section would return to "normal" mode. This is likely one of those things we'll need to "feel" to make a decision on. |
Yes, I mean to include that. I think for now since it's only enabled in site editor root which doesn't have any "layout", we can just check the number of blocks.
We can try things and see how it feels.
Ok, I think I'll always prefer "click" over "hover" though :P |
|
Made a lot of updates here, let me know what you think. |
|
Here's what I'm seeing: exploded.mp4
Edit: The video above didn't demonstrate the flicker, see below (around 5s): flicker.mp4It's tricky to replicate, I'm not sure what is the trigger. |
Is this because it's locked?
Felt the same, that will be my first follow-up. It's not complex, I just want to make it right (move stuff around) without making this PR huge.
I guess, I can just close it for now. We can also decide to leave it functional later. (You select a child, its root parent gets highlighted)
Makes sense.
The flickering is actually a nightmare in Safari. But these bugs are the hardest to track and fix 😬 |
Derp, yes. Will just need to style the toolbar so that it doesn't look strange. Or perhaps include the lock icon? Edit: On second thoughts, definitely include the lock icon. It would be frustrating to have to exit this mode in order to unlock a block you want to change.
I think that would be best. There may be a more unique visual treatment we can apply in this mode. |
This is a bit tricky. I'm not sure I'll be able to do that simply. I can close the sidebar easily on open but disabling entirely is not easy (cc @jorgefilipecosta as it's a complementary area) |
I guess we can not include the slot on the exploded mode? |
I wanted to disable the button, not remove it entirely (like the other header buttons) |
This is a more challenging issue. One solution would be to add an optional prop to ComplementaryArea called pinnedUI and when passed that property would be the toggle button of the sidebar, allowing one to have full control and custom logic for when that button on the sidebar is enable or disabled or not rendered or rendered in a different way. We can also go for a simple property if we don't want to allow that level of control like isTooglingDisabled and when true the button would be disabled. |
|
@jameskoster maybe it's fine for now to just leave it there, or alternatively remove the button entirely? |
|
Yeah probably fine to leave it for now. At least most of the block settings are hidden. |
I think these ones should be blue :D |
|
This is cool! And it sounds like we can add animation in the future, that's great!
I'd echo that. But — hear me out — what if they were all blue? (⊃｡•́‿•̀｡)⊃━☆ﾟ.*･｡ﾟ Can we have an inserter after the last block as well?
|
We can add an animation when moving blocks in the view but between the "exploded" and "normal" view, I'm doubtful (or if you're optimistic, I'm unsure at the moment) |
|
I added an inserter at the end and made all inserters show patterns by default. |
|
|
||
| /** | ||
| * Internal dependencies | ||
| */ | ||
| import BlockListExplodedItem from './item'; | ||
|
|
||
| const InserterBeforeBlock = pure( ( { clientId } ) => ( |
There was a problem hiding this comment.
I didn't know we had this HoC. Should I prefer using this over React.memo?
There was a problem hiding this comment.
To be honest at this point, I don't know. What's certain is that we need to make a decision :P. This HoC was here before React introduced React.memo and if I'm not wrong also works for Class component contrary to React.memo which I think is only suited for function components.
There was a problem hiding this comment.
Right, React.memo works only with functional components.
What's certain is that we need to make a decision
Got it. Use React.memo with function components use pure with Class components 😄
|
I know this sounds like a small thing just focusing on the animation, but I want to poke at it a little more to make sure we're on the right path. Conceptually I don't think of this view as still being the editor view, but in a different mode. Just like Browse Mode where blocks become inert and navigable, these are still the same blocks, just inert and draggable. In that light, I don't know if replacing all the blocks with previews is the right approach. I know the following inspector hack is not representative of the impressive technical challenge, but here the transform is applied to the styles wrapper, and a few background colors are shuffled around: This is the "before" state, for comparison:
That is to say, I think the animation is important, but more important than that, is the flowing in and out of this state. It isn't conceptualized as being a shift — it's meant to be much more similar to select mode. Smooth flowing in and out. |
|
Sometimes when I toggle "Explode" mode, not all sections are rendered. It usually happens after the third or fourth toggle without page refresh. I also noticed that the editor remembers that it's in "Explode" mode. Is this intentional?
|
I'm curious to know what changes you did to the inspector. I agree with you that there were two paths:
It's also true that for the first one it's easier to animate things but I don't think it's the right approach for the two things highlighted in the descriptions and the main one for me is this one: Here we want to apply the editor styles (iframe) to each block separately but we don't want the editor styles to bleed out of the block. And our goal with iframing everything is just to use the "styles" from the theme as is. Meaning if the block itself is not an iframe, we can't apply these styles. I think trying to use the existing BlockList to show this mode is going to be a hack that will always be very fragile. |
|
There's also one question here: Do we want to "scale down" the size of the preview according to a given viewportWidth (current state of the PR) or do we want to always render it as is (no scaling down). I tried both, I preferred the scaled version but I can also do "unscaled". |
I've seen this happen. I think it's a bug in the
Initially unintended but I thought I might just well keep it (like the code editor switch) |
|
@jasmussen I'm exploring the alternative approach here #40376 I'm not sure yet how I feel about it. I don't have the animation there yet but it's easier to implement for sure. |
|
closing in favor of #41156 |
Related #39281 #40319
What?
We want to explore an "exploded block view" where the blocks (and sections) of the top level are separated and the actions for each block/sections are separate from the regular toolbar.
See #39281 (comment)
This PR just bootstraps that mode to allow us to iterate on it.
Why?
I think the reasoning is to make it easy to build templates from scratch by leveraging ready to use patterns.
Notes and questions?
There are already some questions that we need to answer in this initial PR:
edit-siteleveraging existing components (BlockPreview...). I've started with the latter for now but I'd love to hear thoughts.layoutIdbased animation from framer-motion (which are our most promising solution) don't seem to work inside a single iframe, so cross-iframe is even less likely to be possible.BlockPreviewcomponent that we need to find and fix.Testing Instructions
1- Open the site editor
2- Click the "exploded view" button on the header.