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:
So that’s at least two from my side, and there may be more.
3 Likes
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.
3 Likes
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.
4 Likes
David, would it be feasible to have a discretionary API to register “cross theme/plugins" components for use in another plugin/component?
That would avoid registering everything but still provide the flexibility to explicitly make it possible.
2 Likes
I’m not sure about a generic API for this. There are just too many ways to use components, and they all have different expectations around arguments & load timing.
For your use-case, would a theme/plugin-specific registry work? Like the mockup above for right-sidebar-blocks?
If not, providing some concrete examples might help us to work out exactly what kind of API is needed. All CDCK-maintained themes & plugins have been migrated to gjs, and this isn’t a problem we’ve run into (except for the specific cases like right-sidebar-blocks).
1 Like
Yes, actually, re-reading more carefully what you wrote on the Draft PR does lead me to believe this is a good enough solution, specifically:
“This commit introduces a dedicated list of Right Sidebar Blocks components, and allows other themes/plugins to register additional ones.”
I think that is key - being able to register remotely as compatible with another theme and then allowing the “master” theme to incorporate the elements registered remotely is exactly what I’m after, so I think you’ve already demonstrated this is possible.
1 Like
Cool!
In very simple cases, you might even be able to get away with adding a PluginOutlet in the “master” theme, and then other themes can renderInOutlet (or put a file in connectors/...).
2 Likes
Also true. I really like your registration pattern though, very nice. It would be good to retain compatibility with RSB actually (Bars already uses the same param system) so the whole system becomes interoperable.
What would be ideal is if the default blocks came in a theme pack and the “mother ship” in another TC - then Bars could be swapped in for the mother ship role and its extended layout functionality but the pack remains re-used. I appreciate that might be too complex for end-user admin consumption and CDCK maintenance though!