Separation of logic: migrating to Astro Theme Provider

[BryceRussell]

Is your feature request related to a problem? Please describe.

• The blog route is included with StudioCMS. What if a user wants to use StudioCMS independently of the theming/styling it provides? For example, using StudioCMS as a CMS on an existing website. I imagine most user's of StudioCMS will want to use StudioCMS as a backend for content without extra routes like the blog

Describe the solution you'd like

I would like to see StudioCMS be split into separate packages

1. A core package that provides the core functionality and a dashboard for StudioCMS
2. Official themes (blog, docs, etc) that use the core package as a backend for editing content

This would allow users to use the core package if they want a CMS for their own routes (like a traditional CMS), and use themes if they want to use pre-built routes for a blog, docs, etc.

This separation of packages is a perfect opportunity to migrate towards Astro Theme provider. Astro Theme Provider already has the APIs that StudioCMS needs to facilitate this migration, and it would simplify the integration code.

Describe alternatives you've considered

One alternative is to not use Astro Theme Provider, but continuing with the current structure has some problems:

• The problems I have already mentioned in previous sections
• No reason to re-design and engineer APIs that already exist inside of Astro Theme Provider

Additional context

I am willing to take ownership of this issue. I am looking for opinions/permission before tackling such a large change, I am available to chat if anyone has questions or wants a more detailed explanation than what I can do in text.

[Adammatthiesen]

Perfect Timing! #45 is the start of the prep for this!

[BryceRussell]

Awesome! I will be publishing ATP v0.3.0 soon, after that is published and #45 is merged, I want to start working on a draft for this. Is that ok?

[Adammatthiesen]

That should be fine! just let me know if we need any new virtual components added to the helper 😄

[jdtjenkins]

Headless StudioCMS when??????

Yeah I love this idea, as Adam said it's already starting to get more and more separated and more decoupled.

Because I'm imagining something like this:

// astro.config.mjs

integrations: [
  studioCMS({
    themes: [ // don't care about the name, just a placeholder for now
      blog(), // this adds say all the routes for your blog and could even add APIs for you to manage the blog AND adds it's own routes into the dashboard,
      docs(),
      storefront(),
      imageGallery(), // idk but you get the idea
    ],
  })
]

Then we can use ATP to create a whole theme with it's own pages, customisable components and just generally awesome stuff?

Yeah I'm down, I love this idea

[dreyfus92]

I love the idea, the more flexible we are to bring in other integrations sound good to me 🫡

[Adammatthiesen]

After our previous discussions i believe this would be better as multi-step PR. The First, to setup the new schemas and helpers, and the Second, to implement ATP for the front-end.

• Setup new Table Schemas, and Implement Helpers (component and function helpers)
• Migrate front-end to utilize ATP

[create-issue-branch]

Branch issue-0050 created for issue: Separation of logic: migrating to Astro Theme Provider