Expand Rust API

[hollyburn]

First off, congrats on writing a useful and powerful tool with a super readable codebase!

Problem

I'd like to use Grimoire as part of a web framework, preferably keeping my config and CSS in a database. It'd be convenient if I could implement a trait (or a few) for this, so I could e.g. deploy my application to a serverless provider or as a single-file container and rebuild my CSS when an admin user modifies the theme.

Solution

Essentially, I'd like a few currently private structs and functions which accept a directory to 1) be pub and 2) instead take perhaps a vector/map filled with reader/writers, or a single reader/writer in the case where they only use the directory to construct one file's path. Having access to say, ConfigJSON would be useful. It'd be nice to ultimately build shared and critical CSS to a string or writer for storage somewhere other than the filesystem, like in a db or hashmap.

Options

Honestly, the language is so well-specified I would be comfortable implementing this in a new crate if it's not something you're interested in for this project. Or with your architectural blessing, I could take a crack at rewriting the relevant parts of this crate to be less tied to the filesystem - without removing any existing fs-based functionality, of course.

[hollyburn]

Wrote a rough-and-tumble little parser for the Spell syntax over at hollyburn/gramaire :)

I'll be refactoring it into a more useful library, adding features as needed for my project - namely identifying Spells in text files, building Scrolls, and writing out CSS. Hope you're well.

[dmtrshat]

Hi @hollyburn,

First of all, thank you so much for your kind words about Grimoire CSS! I’m thrilled that you find the tool useful and the codebase approachable. Your feedback and ideas mean a lot, and I really appreciate the effort you’ve put into exploring its potential and even creating your own parser.

Regarding your suggestion, I believe that instead of exposing internal structures and functions, a better approach would be to implement this as an optional module within Grimoire CSS itself. This would maintain the current level of safety while providing the flexibility you’re looking for. By designing it as a feature (e.g., database or alternative storage support), we could keep the core library focused and stable while allowing users to opt-in to this functionality when needed.

I’d love to collaborate and help bring this idea to life! To ensure we address all use cases and design it effectively, I’d like to propose the following steps:

1. Define Requirements: Let’s work together to outline the specific features and requirements. For example:

• What inputs/outputs would you expect the module to handle?
• Which use cases are critical (e.g., specific database integrations, memory storage)?
• How should this integrate with the existing configuration and CSS generation processes?

2. System Design: Once we have the requirements, we can design a robust system to implement these features, ensuring it’s modular and efficient.
3. Implementation: With a clear design, we can integrate this as a feature within Grimoire CSS, avoiding the need for a separate crate and keeping everything in one place.

Let me know your thoughts and if there are any specific ideas or requirements you already have in mind. I’m excited about the possibilities and am more than happy to actively develop this alongside you to ensure it aligns with your needs.

Looking forward to hearing from you!