A great feature of BaseHub is that stuff gets committed all at once, creating a snapshot of your repository at that point in time. We haven’t yet seen released the full implications of that git-like workflow, but it will allow you to:
See everything you’re about to commit, and choose what goes in or what gets restored to its previous state.
See past changes across your whole repository, or across a single document, and revert if you made a mistake.
Create branches to work on new stuff without affecting production.
And a lot more.
Now, one inconvenience that “committing everything together“ brought, was that you would struggle to create “work in progress” content, cause you were obliged to commit it, and therefore expose it to the API. Not only that: if you are rigorous with your constraints (which you should), you’d get a bunch of “is required” errors when attempting to commit, and you’d be forced to either lower the constraints, or enter in dummy data.
That’s why we created the “hidden” state. A hidden block will not be exposed via API, and will skip commit validation. You can hide a block via the properties panel, or via the sidebar. You can only hide documents, components, and instances; and nested components/instances inherit hidden state from its parent for convenience.
This is not the same as the “draft/published” workflow that other systems offer. Our “hidden“ state is something that needs to be committed, meaning, everything that gets committed passes the validation you’ve set up, always. The fact that, in other systems, publishing is controlled per-entry makes it easy for users to enter an incorrect state. If you’ve started with loose constraints and at some point decided to tighten them up, then you may have fields that are “required” but that return null from the API. While this might seem like a small thing, this means that their GraphQL APIs can never be sure if a required field will actually return content, therefore struggling to be strict with their types, and therefore making developers be really careful with every piece of data they get from the CMS. This is no good.
In BaseHub, we know that if something has been committed, and is required, then it absolutely has a value. We type it accordingly, and developers can work with types that make more sense.
Additionally, content creators can have their “work in progress” in their CMS, instead of just doing data entry once it’s done.
This was a deeper dive on how some features that might seem similar, were actually thought of from first principles, and an ode to the git philosophy and its ever-evolving implications. As always, let us know what you think on Discord, or on X.