gebo-react-hai: Thoughts on deployment

Yesterday I made some major improvements to the gebo-react-hai. This is a grunt-init template, which produces a human-agent interface for the gebo. gebo is evolving into a multi-agent system, and is an extension of my masters research. Currently, it primarily functions as a web application server. gebo-react-hai enables the human agent to send messages to the gebo agent.

Having built a similar HAI template in Angular, I thought I’d take a similar design approach. I like Angular and React, but they are different tools and so need to be wielded in different ways.

Yesterday I was approaching the gebo-react-hai in the way I had become accustomed working with Angular. In retrospect, I may have been doing Angular wrong anyway, so it was high-time I rethought my approach to React.

Here’s where this post gets boring. I gained no new philosophical insight into my craft, but instead confronted a nuts-and-bolts problem related to deployment. The gebo-react-hai template produces a project, which can then be developed, tested, and built with the help of grunt. When building, you can get grunt to do lots of handy things like concatenate and uglify your code. It was in the concatenation where everything got hairy.

The problem is this: HAI functionality is split between two pages (public and private, basically). After you authenticate and switch over to the members-only interface, you’re loading a whole new web page. Each page has the same basic dependencies, but each has their own custom React components. The purpose of concatenating, minifying, and all the rest is to produce a simple script, e.g.: my-project.min.js. If each page has its own unique dependencies, then there have to be two different deployment-ready files in production. And what if a HAI has even more pages?

Some people may roll like this, but it’s not my style.

Why do all that fancy grunt processing if you’re just going to have to rig a whole bunch of different minified files for each page that makes up your web application?

Why indeed? I was contemplating this very question driving my daughter to kindergarten when I realized that I should pay more attention to the hokey tech buzzwords that people are always dreaming up… single page app! Like duh. By putting all functionality on a single page, I don’t have to spend more time mastering grunt. Deployment is simplified and my software is easier to use for the developer. Again, like duh.

Now it’s time to see how the Bootstrap navbar and nav-tabs get along…