RFC for Astro.extend User/Plugin Space

[tanepiper]

• Start Date: 2022-06-17
• Status: Draft

Summary

RFC for Astro.extend Userspace, where template plugins can be attached in a style similar to jQuery plugins, here they provide lightweight extensions and templates

Links

• Full Rendered Proposal

[crutchcorn]

I worry that this potentially impacts:

• Stability, as highlighted in the RFC
• Code migratability. If the API for this changes, it potentially introduces another source of headache both for devs who use this feature and the Astro team
• Debuggability. Globals are always tricky to stack trace, doubly so with build tooling, where it's harder to filter out stacks IMO

I also am not sure I think the idea of using a global for UI elements in the two defined examples is the cleanest code pattern since it introduces some headache in regards to figuring out the flow of code, debuggability, etc.

I wonder if we're better off being prescriptive about enforcing explicit code imports as opposed to utilizing extend

[tanepiper]

@crutchcorn

• I'd argue stability is always a factor in any user plugin, and of course in any 3rd part integration too
• APIs always change, but if your version correctly, announce upcoming deprecations and breaking changes, it should help and popular plugins will tend to be maintained. Of course, the Astro team have to take on board any risk a feature like this introduces, but ideally through design would find a way to reduce ways to harm users (such as sandboxing certain things)
• Yes debugging this kind of stuff is never fun, but see above - maybe some domain ability could provide a way to capture error context correctly

My initial thinking around this was actually more like Angular pipes, but possibly using the new Pipe operator syntax - but this would require those functions to be made global - with a namespace, at least there is less chance for abuse.

This could be done via a config option where you have to define them explicitly. The idea is to remove the need to import functions over a lot of different components.

Sure in the menu example, maybe this should be a component - but maybe you want to have functions that render certain types of content in a more declarative way, session-based helpers, etc

FWIW we've built an OpenAPI renderer that just imports a library, parses the file and we pass the object through a bunch of components - it works fine, but with our setup, we can't pass the file object back up to get it at a higher level, so now we have to export the internal parse function and call it every file we use it in - to simplify it we now import the getStaticPaths method from our [spec].astro file which has the loader method, and uses the data now on other pages - but it's not really clean.

I'm sure there are better ways of architecting what we're building, but it feels like there's a space missing for easy-to-create small functions that don't need to be a whole component

[okikio]

I'm apprehencive about this in its current form. Personally I'd prefer a singular place where I can go to determine, where plugins, extensions are, it makes it much easier to debug, terse and understand code. Astro.extend would be hard to follow for those new to a code base, or while trying to debug where errors are coming from.

[matthewp]

Is this JSX?

[tanepiper]

It's psudocode :)

[matthewp]

I think some real world use-cases would help this RFC. It's unclear to me what a plugin is or what you'd be using them for. So some examples of plugins you would use/write would make it easier to understand the design.

[tanepiper]

Talking to one of the other devs, I think the best example we could find that would be most explainable is to offer a space to have functions like Hugo - https://gohugo.io/functions

[natemoo-re]

We've revamped our RFC process and this proposal has been returned to a Stage 1 Proposal. For further discussion, please see #536