Thanks! Will be testing today 
Hey @marca, I’m getting 400 bad request errors when Preview function is anything but nearly empty.
Here’s sample code that triggers this for me:
function(instance, preview) {
console.log('This is function PREVIEW...')
// console.log("We are in initialize: ", instance.canvas)
console.log("Nanoid? ", typeof nanoid)
}
And, BTW @marca, this happens even if that preview code is:
function(instance, preview) {
console.log('This is function PREVIEW...')
// console.log("We are in initialize: ", instance.canvas)
// console.log("Nanoid? ", typeof(nanoid))
}
Though:
function(instance, preview) {
console.log('This is function PREVIEW...')
}
WILL produce a log.
What I was trying to do here, BTW, is simply see if libraries called on by the plugin get loaded in the editor, but I’m guessing not? This makes it difficult to do any sophisticated sort of preview, right? (Because if you have a visual element with any styling, you need to have unique classes to properly style multiple elements in the page. Personally, I do this by generating UIDs with nanoid that become part of the class names.)
(Though I don’t seem to be able to do much of anything with the preview function at the moment…)
1 Like
“This makes it difficult to do any sophisticated sort of preview, right?”
+1 to this.
@keith Based on my tests the libraries are not loaded in, which really does seem to limit the potential of this preview feature. Perhaps I’m approaching this the wrong way - but is there a best practice for loading libraries into the Bubble editor, or an alternative method to simply adding the script/library to the DOM with each instance of the plugin element?
1 Like
Hey @marca, I noticed you used some ES6 syntax (template literal and “let” keyword) in your sample preview code. Does that mean plugin code is transpiled by Bubble before deploying? IOW, is it ok for devs to use ES6 syntax?
No transpilation, read nothing into that past me ignoring the existence of IE.
@marca Did you manage to locate the 400 error issue described by me in bugreport and by others in this thread?
Fixed a month ago: [New Feature] Plugin preview rendering
And @sudsy, I should add that in general, while we go to considerable effort to make Bubble apps IE compatible, this does not extend to the editor. So within the limited scope of this particular function, have at it.
1 Like
Makes great sense. Thanks!
You linked to the 401 bug above.
There was a separate issue that arised causing 400 errors. I sent in a bugreport and a PM. Others also reported it here in the thread.
I havent revisited it since, so may be fixed but if you didnt see the bugreport it might have slipped by you.
Thanks in advance!
It seems even more limiting than that. Unless I’m overlooking something, it appears only properties that evaluate to strings are available in the preview function. All other properties (lists, objects) are null. Perhaps that’s what’s meant by “Arguments are simplified versions of the arguments to update.” in the description for the preview function. 
@sudsy Youre right, keep in mind that these components render in the editor where there is no context of the end user and the connected dynamic data (DB queries/states). So this data that would be displayed to the end user is thus not available in the editor. The properties available are those exposed on the component properties panel in your editor as you pointed out.
It would not make sense to display the user connected dynamic data unless Bubble would have a feature in the editor to “preview as user” in the editor UI itself or a feature to define mock-data/mock-queries per page.
You could render example data where the static inputs were not sufficient. Just create and use a static JS object.
Oh yeah, good point. Context matters. 
In this case, the data I need is not user-specific, but I’m not sure if/how it can be retrieved.
Given the “App Type” (type of Thing, which does appear as a string), I’d like to retrieve information about the fields of that type for my preview.
Not sure if that’s possible, so maybe I’ll start another topic on it. (Seems you can get that info from an instance of a Thing, but it’s not clear if it’s available with just “type” information.)
Hey @marca, I know this is going to sound weird, but is there any chance that there’s an insanely low character limit on the plugin preview function?
Yesterday, I submitted bug #7300, and I have been banging my head against the wall thinking I had a logic or syntax error, but what I’ve learned (after literally hours of troubleshooting) is that reducing the size of the function body resolved the issue! 
The preview function of the plugin exhibiting this issue is less than 3K, but when I delete less than 1K of code (or just comments!) - i.e. simply reduce the size of the function body, then it works!
Is it possible that the amount of code allowed in the preview function body is off by a factor of 1000 or so? 
Unless you’re on Internet Explorer, the character limit ought to be significantly higher than that, in the tens of kb. I actually just touched this code on Friday, so it’s entirely possible I broke something. I’ll have a look!
1 Like
Great, thanks!
I don’t know if you saw it, but this post references the same server-side error (http status code 400), so perhaps it’s related.
1 Like
@marca, fonts specified in the property editor aren’t rendered in the plug-in preview. See here.
Is it possible that the fonts are not being loaded into the iframe that hosts the plug-in preview?
It’s not just possible, it’s for sure. See my comment on your other post.
@marca: gauntlet thrown, please to pick up. 
+1 too… @marca could you just double confirm that we’re (I’m) not missing something, and that it’s not possible to load libraries as part of plugin preview?
Thanks
1 Like
