Update Visual Editor to support custom preview devices/styles#1
Update Visual Editor to support custom preview devices/styles#1jcheringer wants to merge 4 commits intotrunkfrom
Conversation
ice9js
left a comment
There was a problem hiding this comment.
This looks decent, although I believe the deviceType setting should be independent from deviceStyles.
It feels to me like shouldIframe really is the problem here, that it's hardcoded to deviceType, so maybe that's what we need to change? But I'm also open to ideas.
| }; | ||
| let animatedStyles = desktopCanvasStyles; | ||
| if ( resizedCanvasStyles ) { | ||
| if ( deviceStyle ) { |
There was a problem hiding this comment.
Do we really want to overwrite animatedStyles or just augment it?
| <MaybeIframe | ||
| shouldIframe={ deviceType === 'Tablet' || deviceType === 'Mobile' } | ||
| shouldIframe={ | ||
| deviceType === 'Tablet' || deviceType === 'Mobile' || deviceType.indexOf( 'iframe' ) !== -1 |
There was a problem hiding this comment.
This feels a little hacky 🤷 But then we don't want to hardcode things either...
How about if we added a dedicated setting for shouldIframe and deviceType = 'Tablet' | 'Mobile' just overrides that.
We actually want to keep the deviceType's as they are and use the styles in addition to it. As in, ideally, you should still be able to preview a popup on the desktop, tablet or mobile.
Hence we maybe don't want to actually set a deviceType for our purposes.
|
Thanks for taking a look, @ice9js! 🙇 |
Those are the minimal necessary changes I found to allow us to add custom device types.
I think the 'device type' term isn't the best description for this. 'Preview type' seems more descriptive, IMO, but I didn't want to mess with the already used names.
With these changes, we'd be able to do something like this on our side:
Using the term
iframein the device type name would indicate that this preview should render inside an iframe.