Developing Plugins Faster by separating the frontend into a theme component

dev
1

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.

7 Likes
2

Yes, that’s a good approach.

I’ve used that approach on Topic List Previews for a while now, moving as much of the functionality into the TC as possible and making it stand alone. Additional features which require API modifications then go into a plugin and users are encouraged to install that too to take advantage of them (if they can).

The only issue with this approach is if you are sharing your code and API modification is a necessity, then you have to make sure someone installs both components. Splitting them into two is not the most convenient way for people to then consume your work, potentially, so I still think that ultimately a single plugin install is still the best approach for open source work of that nature.

If it’s just for your own site, then sure, this is great!

3 Likes
3

Yeah there are certainly situations when ultimately you want a single codebase. The lightbulb moment I had was that even if I want a single codebase in the end, I could code all the front end stuff in the theme component, and then once that’s working, move it to the plugin. A little tedious, but overall way better for me because I’m still spending most of my time coding in the theme component work flow.

2 Likes