Having grown up in the 80’s, I remember when thumping the top of a TV to make the picture show up again was actually the commonplace approach to fixing things.
It was a glorious era of soldered wires of dubious quality, whether it was in cars or TV sets.
But why all that nostalgia now?
We like to think of professional software development as a combination of engineering & art.
It requires core tech skills, accumulated practical knowledge, and styling choices that are about aesthetics as much as they’re grounded in rationale. But there’s also a good amount of, well, knocking on the top of the TV involved.
It’s almost inherent: we’re sculpting the correct flow of code out of our first rough attempt at it, and it’s not taking place in a clean room. Just like most art.
Looking at the developer experience with Stackbit, a big part of it involves working to model content elements in the right way, define which knobs and switches to provide to the content editor, and correctly annotate your components for visual editing.
Till now, as a developer you needed to make a choice of how to work.
You could either:
Work locally with your favorite tools and with full control of the environment - but without seeing the resulting visual editing experience in our web app until you push code to the preview branch.
Or, work online using the built-in code editor. Any changes you make affect the preview immediately (and get committed right away), but you lose the ability to control your dev workflow the way you want it, and you have less visibility and control over the runtime environment.
Practically, most developers we’ve talked to are switching back and forth as they work, but clearly this isn't ideal.
So, we’ve decided to bring local back:
You should be able to work locally, fast, while getting the full visual editing experience, updated immediately. So you can iterate with the velocity that you expect.
So, how does this work?
First, you run your site on your local machine as you would normally do. That’s typically as simple as running npm run dev.
Next, you run our updated command-line tool: stackbit dev, pointing it to your project folder. Here’s how the output will look like:
Click the link and the Stackbit web application will open in your browser, showing your local site. You can now visually highlight elements, make content changes, change code in your IDE - everything just works, in both directions.
What enables all this is the “proxy” process you’ve just launched. It forwards whatever your site is rendering, but adds a layer that takes care of highlighting, content changes, and more.
What about branches and commits?
This is totally up to you. You decide with which repository and branch to work, and what and when to commit. Push the code to the preview branch when it’s ready, and content editors will get the updates.
Let me share an open secret:
You don’t even need to base your work on an existing Stackbit project. Whatever codebase you clone (or develop from scratch) that Stackbit can work with, you can use local dev mode for.
That means you can experience a large part of the Stackbit developer experience without even creating a project in the Stackbit dashboard.
Here’s a final tip for you:
Work iteratively. Add an annotation, test it, repeat.
Use the stackbit validate command line tool to check your schema.
Don’t code a whole bunch of components in a frenzy and then try to make sense of why visual highlighting looks messed up. Unsurprisingly, the same methodical approach that you should employ in almost any coding project applies here as well.
What’s next?
Local dev is now available for projects based on our Git-based CMS. Support for Contentful is coming Real Soon Now (TM).
The larger story here is not just development on your local machine, though.
It’s about "Bring Your Own Development Environment". Whether you want to run with cloud-based IDE’s (such as Gitpod) or your own cloud VMs, we want to support that - so there’s more coming.
