Starting the implementation of user options (preferences) in CWiki (a personal wiki program) got me thinking about refactoring the project into a shape that is more compatible with Stuart Sierras reloaded workflow. Naturally, that led to thinking about his component architecture. Here are some more resources related to the component architecture.
- Stuart has a blog post about his reloaded workflow, linked above.
- The component code repository is on Github here.
- The system repository contains many examples and ease-of-use functions.
- The blog post Retrofitting the Reloaded pattern into Clojure projects talks about how you can adapt an existing project to one that can use the reloaded workflow.
- A video on the use of component at Walmart
- A great StackOverflow answer about how to use the architecture.
So, starting from these resources, I tried to retrofit the component system into CWiki. After about a week’s worth of effort, I just gave up. If you have the repository, you can examine my effort in the “experimenting” branch. I got several subsystems working, like the configuration, database, and server, but it just seemed like one complication after another. I wanted to get back to working on features and bugs, so I abandoned the branch.
Something I Learned
One of the key concepts in working with the component system is the elimination of global state. That’s good for functional programming in general too. So it gave me a chance to go through my code and eliminate as much global state as possible.
The most straightforward technique, and an absolutely obvious one that just never occurred to me was to replace
defed vars with functions that returned the same data. Duh! Now I’m trying to get in the habit of replacing all of my global state data with such functions.
Maybe someday in the future, I’ll complete the retrofit. Or, more likely, I’ll try it at the beginning of another project.