I’ve previously asked about how to setup the local environment to code faster when building a plugin, and I know others have as well.
I’ve been using a new workflow that’s been working great, and I thought I’d share in case helpful to others. It doesn’t solve everything, but makes things a lot more pleasant. Here are the details:
First, my previous issue:
To develop a plugin, I had to code from a local instance of Discourse, and this was really slow because: 1) any change to files would require reloading the page, and my computer would do that very slowly when running Discourse (about 30 seconds per page reload), 2) the local discourse site for development I would test on would be very slow (slow to navigate, etc), and 3) any change to backend plugin code would require stopping the server and restarting–and this could take a few minutes. All the while, my computer’s fan would be blasting.
As a result, it would probably take me an hour of coding to do what I normally could code in about 10 mins with a smooth work flow.
My Solution
In contrast to developing a plugin, the work flow for coding a theme component is awesome, thanks to the Discourse theme CLI. (My steps for using that are here.) It’s fast and smooth.
Why coding a theme or theme component is so much faster and easier
With the theme CLI tool, you can code a theme locally, but “watch it” (ie, run the theme) on a live site (either your actual site, your actual site but just in preview mode, or a test live site you set up).
So you don’t actually need to run Discourse itself on your machine–and therefore my machine doesn’t slow down like it would with a plugin. And whenever you make a change, you just refresh the live site you’re linked to, and the change is there.
So, what I realized: most of the time when I’m coding a plugin, it’s actually on the front-end stuff (hbs files, javascript files, etc). And only a little of it is spent on the backend stuff (setting up routes, creating custom fields, etc.)
Instead of coding it all together, then, just move all the front end coding to a theme component, to take advantage of the theme component workflow.
When I have to update the backend stuff in the plugin, then I have to code in the plugin again–but that is only about 20% of the time (in my plugin development anyway). Allowing me to now spend 80% of my time with the much nicer theme component workflow.
When it comes time to move everything to production, I can:
-keep the theme component and plugin separate, and just use them both on the relevant Discourse site, or
-if it’s important to have all the code in one spot, at that point move the theme component code into the plugin. Admittedly that can be a little tedious, but you’d only have to do it once you are ready to update for production, all the while enjoying the faster theme component workflow.
That’s it.
Not revolutionary. But it’s made things a lot better on something that tripped me up for a while.