At the end of October 2017, I wrote about the new and upcoming changes to ContribKanban.com. I decided to migrate off of a MEAN stack and go to a more familiar (aka manageable) stack. I decided upon Drupal 8 to manage my backend. Drupal is what I do, and Drupal is amazing at modeling data. People can moan and whine - it handles data models like a boss. I decided to treat it as a "progressively" decoupled web application.

WTF is "Progressively Decoupled"

I caught myself at Florida DrupalCamp, MidCamp and other conversations calling the new ContribKanban.com a progressively decoupled application. Which made me wonder, what in the hell does that really even mean? Well, according to Dries back in 2015, this description seems to best fit how it all works:

where the skeleton of the page loads first, then expensive components such as "songs I listened to most in the last week" or "currently playing" are sent to the browser later and fill out placeholders.

Drupal 8 handles routing, data, and initial rendering. Then the client picks it up in the browser. And that is how ContribKanban.com works. Drupal is a data storage for Drupal.org API query configurations. When you visit a board, Drupal gets that information and bubbles it up to the client via the JavaScript API's drupalSettings. Then the client side scripts take over and render fancy kanban boards off API results from Drupal.org

So, I guess it's a decoupled progressively decoupled application. Data comes from Drupal.org over RESTful interfaces and board configuration comes from the Drupal instance via its render and template system.

Makes sense, right?

Why I chose ReactJS

October 17th through about the 26th I had a sprint of activity rebuilding ContribKanabn on Drupal 8. I had built the entities for board and list storage developed design patterns for representing the board configuration in drupalSettings, had my JavaScript built out - the whole nine yards. In fact, I had even managed to kill the requirement of jQuery and have it nearly fully functional. While that made me feel like a badass for not needing to depend on jQuery and use VanillaJS, I hit a brick wall. I need to support a few very specific requirements

• I needed to be able to allow users to filter by issue priority and issue type when viewing a board, causing the lists to re-render and filter by this constraint
• I needed to be able to take a project node ID and translate it to the project title within a card
• I needed to be able to take a user ID and translate it to their username when assigned to a card.

In AngularJS I knew exactly what to do. Use a for loop and then two directives. Boom. Done. In plain old JavaScript, I was not sure the approach to take. I had read a lot of hubbub about Polymer and web components, especially thanks to content by Bryan Ollendyke. I had played around with Angular but didn't really love the next generation of its development (maybe blame TypeScript?) I knew the popular kids on the scene were React and Vue.js One is developed by Facebook and has a huge community following and the other seems to be React filled with those who want to flip the bird to corporate-sponsored open source projects*. Plus it appeared (and it true) that the Drupal core Javascript Modernization Initiative would pick React and get started at improving Drupal's ability to decouple.

So I picked it back up and decided to move forward with React so I could solve my user interface woes. I blogged about some of my first experiences using ReactJS, which was pretty enjoyable. I'm happy with my choice.

* I know I probably offended a handful of readers, there. But when I've asked people the difference between Vue.js and React there have been no defining differences. You have JSX and Nuxt. I understand where Vue.js is different than Angular. But the micro differences between React and Vue.js seem very minuscule.

What's under the new hood?!

So! What's under the new hood? Now that I don't need to manage running a MEAN stack and can just do what I do best, I can focus on features and general improvements.

Manageable data model for boards and lists.

In the original version of ContribKanban, boards and lists were one giant JSON blob in MongoDB with some overrides in a JSON file for how the board should appear. There was no administrative user interface. When Parse.com went away it made my life a living hell. The project became stagnant and undeveloped. So this brings new life and management. yay!

Super duper custom boards and configurations

One of the best things about this switch is the fact it is a user interface for Drupal.org's API. An example of such a board can be found here: https://contribkanban.com/board/1. That board is for Lullabot's AMP projects on Drupal.org. It combines the module and theme issue queue into a single board.

Another example is the Drupal Core Novice board, https://contribkanban.com/board/DrupalCoreNovice. It contains issues for the currently active Drupal 8 branches that are tagged as Novice, but only of "normal" and "minor" priority.

User accounts for more awesome things

I wanted to also allow for people register user accounts so that there can be user-based data. One such thing is to display issues of projects that a user maintains, or at least the recently updated issues that they follow. Creating accounts also allows me to figure out privileges for creating custom boards and owning project boards. As a maintainer of Commerce Reports may I want all issues to filter on a parent issue which I use to track as goals for the next release.

This is an example of the "Your Issues" tab on your Drupal.org profile parsed into a kanban board when you have an account and provide your Drupal.org username.

A board of custom issues

One of my first AngularJS projects was a Chrome app to track all the issues we needed to be resolved for our SaaS product built on top of Drupal. Shawn McCabe also pinged me about a similar requirement, but a way to track their "Looking for Work" board to give guided down-time contribution work at AcroMedia, Inc.

You add issue node IDs and create custom boards. Pretty easy way to build a sprint board without needing issue tags, especially if it's a private project.

Next steps

Next... I need to fix some lost functionality - such as browsing by branch. Browsing boards is lacking finess, but analytics show most people enter the application via direct links than discovering boards.

I would also like to add OAuth2 authentication. The idea would be to provide a browser extension that lets you authenticate to ContribKanban and add issues from Drupal.org to a node board inline. Similar to "following" an issue, it would let you add an issue to an existing board or create new boards.

I would also like to experiment with GitHub integration, as some projects use GitHub as well.