Blog

SPHERE Insights: A Developer’s Guide to SPHEREboard

April 9, 2020
EmailTwitterLinkedIn

SPHERE Insights is an ongoing column written by various members of the SPHERE team, highlighting unique viewpoints and expertise. This article comes to us from Developer and in-house innovation genius, Josh Gribbon.


As we’ve grown as a company and development team we’ve made a lot of changes in the processes and strategies we use. Some changes make the product better for the user, and others make it easier for the developer to work on the product. Today I wanted to go on a journey through my favorite of these changes, which makes improvements for both developers and users. We’ll start with why we considered making a change, the research that we did before committing, the implementation process, and the results we’ve seen in the year since the change has been made.

Motivation

SPHEREboard was created using .NET Framework up until major version 3, where we did the migration alongside a large refactoring effort focused on our server-side code to simplify and reduce repeated blocks of code. After a successful cleanup of the server-side code, the client-side JavaScript and CSS were the next large target for improvement. We needed to clean up repeated and complex UI components, address general development headaches, streamline needlessly complicated JS logic, automate module “resets” and simplify the process of debugging layout issues.

Research

In recent years the common solution to this problem is to use a JavaScript framework, with the (subjective) top choices right now being React or Vue when you’re adding into an existing project and are building a fairly complex UI. We went with Vue because it seemed to be simple to get started with while also having the ecosystem to add additional features as we built out the system and needed higher-level functionality.

In addition to using Vue, we wanted to use a UI component library so we could build out interfaces faster and without having to worry as much about browser compatibility and small implementation details. We went with Vuetify because it seemed to be the most mature and supported library in the ecosystem, while helping to quickly build out a presentable interface.

Implementation

After the core architecture of the new module was ironed out, we were tasked with developing an initial implementation plan to add Vue to the codebase. Following the multi-step implementation (including creating a new page on the site fully powered by Vue and building the components for the new module), we were ready to fully dive into the new interface effort. We started to see benefits from the change fairly early on in this stage. As requirements changed and we needed to modify and refactor the code, it proved to be much easier than before. We were able to take on the following frontend initiatives shortly after this initial implementation effort:

  • Increase test coverage and facilitate test creation for our Vue components
  • Implement interactive component documentation
  • Makeover additional modules

We got a nice clean implementation and also set the foundation to use components piecemeal in existing interfaces, in additional to the full SPA interfaces that we make for new modules. Through this we also found out how we would drop in new components to existing interfaces as we worked on new features.

Benefits

The implementation was a significant development milestone. Some immediate benefits included:

  • Upgrading JS to ES6, adding many new useful features
  • Single file components(SFCs), the suggested way to write components in Vue, presented us with a semi-magical way of keeping all UI concerns in one file, instead of the usual way of being spread out over 3 different files
  • Transpiling code as needed to help ensure that it still works even when the client doesn’t use an evergreen browser and can’t use the newer JS features
  • Increasing testing enabling test-driven development
  • Maintaining a nice-looking and easy to use documentation site, via VuePress for documentation, which is generated from markdown files and can be deployed as a static site
  • Leveraging VuePress’s ecosystem of themes and plugins to extend the base functionality

Closing Thoughts

If you’re part of a software development team, I encourage you to not be so scared of large rewrite or refactoring efforts when you think there will be a worthwhile benefit as a result. Do your research, talk to the team, make a plan you’re confident in, and then have confidence in the process.

If you want to learn more about Vue their official guide is the best place, and also some of the best software documentation I’ve ever seen. I found myself going back to their documentation more often then StackOverflow because it was the best source and easy to find what I wanted quickly. The Javascript world is exciting, ever-changing, and full of interesting projects, so be sure to do your own research and choose the tools you think are best suited for the situation! After using Vue for several years I’m still very happy with it, but I also think Alpine seems like a great alternative when you don’t need all that Vue has to offer, and Svelte seems really cool if you’re concerned about a framework adding to your bundle size. If you don’t like Javascript then Elm truly does seem like a delightful language.

If you want a sneak peak of what the SPHEREboard front-end looks like in action, you can explore:

  • The SPHEREboard page on our website
  • This blog post recapping the second module redesign
  • Our latest release notes, where we extended functionality in the new interfaces
  • OR reach out to your sales rep for a full demo

P.S. If you enjoyed this, be sure to check out the first post in this series, Starcraft and Cybersecurity!

Stay in the loop

Join our mailing list and get notified of the latest SPHEREinsights