Control Canvas Height

Hello! :wave:

From an engineering perspective, designing a plugin system in a web context is no simple task, especially if you’re aiming to ensure security. It’s a topic that many companies have delved into deeply. If you’re inclined to explore it, I recommend this Figma article:

The crux of the issue is this paradox:

[…] we wanted to make sure plugins would be safe for users to run, so we knew we wouldn’t want to simply eval(PLUGIN_CODE). That is the quintessential definition of insecure! Yet, eval is essentially what running a plugin boils down to.

The TLDR is: currently, the best solution for permitting unsecured third-party code for network requests or creating some UI is to use iframes in conjunction with a postMessage() messaging system.

But iframe is a solution that comes with a staggering number of limitations.

Once we’ve come to terms with the fact that we — or anyone else operating in “userland” — can’t do anything about these limitations, what we can do is aim to provide an SDK that allows for an “acceptable” level of convenience to execute common operations.

Now, talking about the more concrete problems :slight_smile:

If the autosizer is not functioning, this is a bug and we need to fix it (btw, DONE!). However, we cannot allow a dropdown to “break out” from the iframe. It would be nice, but it’s simply not possibile.

This means that any select/dropdown with an overlay will always look horrendous if used in a field extension :smile: The component we provide is more suitable for other hooks, like custom pages, custom sidebars, where the vertical space is not so limited.

This doesn’t imply that one cannot contemplate introducing new hooks if this scenario is common! For instance, something that allows plugins to associate multiple actions with a field via a single “native” dropdown could be very easy to implement:

About field extensions

[…] iframes sometimes aren’t rendered at all (like if the field is hidden or in a collapsed fieldset)

The iframes related to the fields are not rendered… when the field itself is not rendered. If a fieldset is collapsed, and its internal fields are not visible, why should we render the plugins related to those fields? Their job is to extend the field… but the field is not there! I wouldn’t consider it a bug, but rather a consequence of the purpose for which field extensions were designed.

I feel similarly about the idea of supporting the concept of “hidden fields” (that is, present but invisible). What would be the purpose? It seems to me a workaround to have some custom code somehow linked to a field, even when the field itself is not present. If this is the need, field extensions are not the appropriate tool.

We should also always take into account the potential large-scale issues that certain decisions may cause. Some clients have hundreds or thousands of fields within a single record, and removing every field when you collapse a fieldset can also help to decrease the sluggishness.

If you want to manage the form in its entirety (ie. coordinate multiple fields), there are other hooks available, like the suggested form outlets. Are existing hooks inconvenient/unfeasible? Again, let’s define the specific use cases, and we can evaluate whether to extend their functionalities, or to introduce completely new ones!

To wrap up…

Certainly, I haven’t been exhaustive in covering all the topics discussed in the thread… but I was more interested in conveying the general philosophy and approach we used in designing our SDK, so
as to better guide future requests in a way that makes them more easily actionable.

There’s no need to burden existing hooks with more responsibilities than they already have. Let’s try to define what would be nice to have, and we can find/introduce clean and specific ways to get there (if the iframes allow us, of course!)

Sometimes, the cleanest solution to a problem may not necessarily involve the concept of plugins, but rather exploit other tools that we provide, such as webhooks.