I Built Cue All Wrong

Well, not all wrong. But definitely not all right. Over the weekend, I was curious about how to solve some architectural problems in Cue, and so did some learning with the Real World Rails projects. It’s a great way to go deeper into Rails patterns, by seeing what various projects have done.

And I should have done something like this long ago, back when I converted Cue to be a rails project. I did it to force myself to learn this new (to me) framework. But I was so focused on Cue that I didn’t really get my head around Rails, it’s patterns, and the general approach. Or at least, not as deeply as I would have liked.

Doing the research this weekend led me to looking through the Fizzy code. It’s fun to explore a codebase that is so clean, clear, declarative.

And it’s got me excited for where I can take Cue.

One of the challenges I tackled early on was making Cue very responsive to quick keyboard usage. In doing that, I veered away from some core Rails tenets, because it just wasn’t quite responsive enough. My stimulus controllers got messy and complicated. My domain model never really got fleshed out the way I’d like it to be.

Regardless, I’m looking forward to using some of what I’ve learned, learning some more, and then moving Cue to a much better architecture. So that it’s easier to add new features, like my pain of a pane.