Plug-in preview font rendering

[sudsy]

I’m creating a plug-in with a UI (will actually be visible on the page), and I’d like to leverage the preview rendering feature, but I’ve encountered some weirdness.

I want to allow the user to configure the appearance of a <button> element, including the font. I enabled the Font style setting in the plug-in’s Bubble properties section, and I get the font info in the properties.bubble object passed into the preview() function.

The main problem is that the font selected in the property editor is not reflected in the plug-in preview, although it does render correctly when the page itself is previewed…

I did verify that the font face IS being set properly in code, and other settings work fine - e.g. text justification, font weight, etc. It’s as though the font itself is not being loaded within the iframe used to render the preview.

I’m starting to wonder if it’s a bug but thought I’d check to see if anyone else has done this successfully.

[keith]

Yeah, the whole iframe thing is funky, right? The issue here is that your preview code runs in sort of a sandbox (the iframe). So, it doesn’t share any code with what’s going on in the editor page.

So, if you desired to show a font there, you’d have to load it in the preview routine, which becomes a little bit crazy. (Even if, like me, you write all of your code in the initialize routine and then just call the functions defined there in other places.)

And since there’s no mechanism for loading scripts your need in the iframe, you have to bootstrap everything in the preview function. This gets double-plus-crazy really fast.

Like, Bubble almost surely uses Google Font Loader to load fonts. But you don’t have that loaded in the preview iFrame. So you’d have to do something like what my LOADERR plugin does and manually add Google Font Loader to the page (which in this case is the iframed page) and then call it. It’s just crazyballs and probably won’t work because it seems like there are limits on how long the code in preview can be?

(Can anyone confirm if that was ever fixed/changed?)

Basically, the preview function as envisioned now is useless-ish. You can use it to do cute tricks like what I do in LOADERR and the latest version of List Shifter, but you can’t build an accurate preview of a dom-rendered element (which would seem to have been the motivation for this… so, it’s a little hard to understand why we have it at all).

Maybe the team at Bubble could enlighten us a bit with some video docs about how the heck you’re supposed to do anything useful (by which I mean – representing a preview of a graphical element) with the preview function. (There’s lots of neat stuff you can do with it, but you can’t – for example – build a preview of something like Calendar Grid Pro – or even your simple, styled button without a LOT of chicanery.)

Aside: Somebody prove me wrong, please, and give us a lil’ demo of how you do this.

[sudsy]

Thanks, @keith.

@keith

Yeah, the whole iframe thing is funky, right?

“Sandboxing” custom plug-ins in some way, shape, or form is certainly understandable given the havoc a rogue plug-in could wreak with the editor environment (intentional or not).

But yeah, I agree. The current implementation is far from ideal. It sure seems like there should be a way to reuse code from the initialize() and/or update() functions.

@keith

It’s just crazyballs and probably won’t work because it seems like there are limits on how long the code in preview can be?

(Can anyone confirm if that was ever fixed/changed?)

If you’re referring to this issue (further described here), then yes, I can confirm it was indeed eventually resolved.

@keith

you can’t build an accurate preview of a dom-rendered element (which would seem to have been the motivation for this…

Yeah, that’s it in a nutshell. I’m hoping it’s just an oversight - a line of code the dev team overlooked to make fonts available to the plug-in preview.

However, I can also understand the need to keep the editor as lightweight as possible, and it’s easy to see how loading anything but the bare essentials into what amounts to a separate web page for each custom plug-in could adversely impact the whole editing experience.

That said, I guess I’ll try loading the fonts myself.

And oh yeah, as a side issue, have you noticed that the font_face property is made available as “Barlow Semi Condensed:::100italic” where the name of the face and its variants are separated by 3 colons? That format is unfamiliar to me, although it’s easy enough to parse.

EDIT: In fact, when I discovered this, I was certain that was the reason the font wasn’t rendering properly, as I was initially just assigning that value to the CSS property of the same name! But even after parsing out the font-face property and assigning only that, still no joy.

[Appkit]

Preview function still doesn’t style fonts correctly, we made a bug report and is being considered to change. There’s also an issue when styling user uploaded custom fonts on front end.

<div style='font-family:${properties.bubble.font_face().replace(':::custom','')}></div>

[lottemint.md]

$.customLoadFile = (url, type, callback) => {

    $.ajax({
        url: url,
        dataType: type,
        success: callback,
        async: true
    });
}
$.customLoadFile('//fonts.googleapis.com/css?family=Lato%7CBarlow:500%7CBarlow:600%7CBarlow:700%7CBarlow:800%7CBarlow:italic%7CNunito:italic%7CBarlow:regular%7CNunito:regular%7CNunito+Sans:600%7CNunito+Sans:700%7CNunito+Sans:800%7CSpace+Mono:italic%7CNunito+Sans:italic%7CSpace+Mono:regular%7CNunito+Sans:regular%7CTinos%7CRaleway%7CCousine%7COpen+Sans%7CDroid+Sans%7CDroid+Serif%7CEB+Garamond%7CPT+Sans%7CUbuntu%7CLato%7COswald%7CABeeZee%7CSource+Sans+Pro:300%7CSource+Sans+Pro:400%7CRoboto:100italic%7CRoboto:300italic%7CRoboto:regular%7CRoboto:italic%7CRoboto:500%7CRoboto:500italic%7CRoboto:700%7CRoboto:700italic%7CRoboto:900%7CRoboto:900italic%7CRoboto+Condensed:300%7CRoboto+Condensed:300italic', 'text', (result) => {

    instance.canvas.append(`<style>${result}</style>`.replace(/\s{2,}/g, ' ').replace(/'/g, '"'))
})

Try this one. It loads the same fonts as the Bubble does (I’ve picked up that URL from the Browser’s Network tab).

[Appkit]

Great thank you

[lottemint.md]

@sudsy

But yeah, I agree. The current implementation is far from ideal. It sure seems like there should be a way to reuse code from the initialize() and/or update() functions.

I had the same question.
I decided to create a separate JS file with the common functions.

So, you can make them globally - and then access them from your plugin elements.

BTW, regarding the CSS.
Please note that the plugin preview differs sometimes a lot compare to the preview page.