When to switch themes/plugins to `.gjs`?

[merefield (Robert)]

@david

But if we’re talking long-term here, then we should be aiming to avoid looking up components on the Ember resolver. Once we eventually enable Embroider’s “static invokables” flag, the resolver will be empty.

I think we need a general way to do this, which is specific Theme Component agnostic - like we have now.

I’ve another Theme Component that uses this technique:

The Home Pages Add-on - integrate static content from Landing Pages and add...

So that’s at least two from my side, and there may be more.

[nolo (Manuel)]

@merefield

I think we need a general way to do this

I agree. I’ve built a collection of block components, each stand-alone, rather than bundled in one package: Blocks · GitLab.

Right now I can put these blocks on a dedicated homepage with my Homepage Blocks component, just as I can use them with Right Sidebar Blocks, or on Bars.

I recently did a play on the Central theme where I needed a custom sidebar layout. I could easily just build a block framework for a custom sidebar and put block components on it: https://central.kostka.studio (as well as putting the Powered-by-discourse component on the sidebar, just by referencing it by name)

Stand-alone block components are really the most useful tool I have right now for building client customizations in a flexible and maintainable approach. It would be great to have a general path forward to support this.

[nolo (Manuel)]

@merefield

I think we need a general way to do this, which is specific Theme Component agnostic - like we have now.

I’d like to bump this as I’m trying to figure out the best way to handle my components. Right now I see two options that both have major downsides: I could create a registry per theme component that renders blocks, but it sort of defeats the whole modular purpose. Or add one globally through a plugin, but then my components become dependent on that plugin being installed.

So it seems like having a global block registration API in core would really help. Something that theme components could use to invoke block rendering and also to register new blocks.

I love working with the block approach because it lets me split concerns between app layout and component content. The block component just handles rendering its content, then gets rendered by another component in the app. I can drop all the route and outlet logic from the block component, and I can easily reuse the same block multiple times on a layout and even throughout the app.

I find it makes everything leaner and more reusable and it’s overall an elegant approach. Having solid support for this pattern in Discourse would be great.