vrbtm.co development stream | Week X
Content versioning and a bug fix
Not sure what this is, start here with our README, or catch up on the last stream, vrbtm.co development stream | Week IX.
Wes and I are meeting up irl and working at the DUMBO West Elm Brooklyn Roasting Company cafe. Yeah, we bougie af. Today’s date is November 20th. We planned a certain set of features to be implemented by today and we’ve got all of them deployed to beta except for one. Content versioning. That’ll be the primary focus of today.
I’ve noticed that we’re still using “Verbatim” throughout our product even though we decided that our name is going to be “VRBTM”. Going to quickly substitute all instances of “Verbatim” with “VRBTM”. We should probably also rename our Slack team to VRBTM, too.
Wes also spotted a bug with the content status indicator that I’m going to fix before jumping into content versioning. Basically, it’s tracking views when the sender unlocks the content, when it should be for the recipients only. Pretty easy fix. Also updated the email notification logic to include the sender name of VRBTM instead of just the email (no_reply@vrbtm.co). This was also straightforward but involved searching through Sendgrid’s Node library repo for example usage.
Turns out that the wifi at West Elm blocks Filestack and any other sites that are classified as file storage. Can’t really develop a content approval platform if I can’t upload/download content.
We moved to the Brooklyn Roasting Company in DUMBO where the wifi allows for all the things.
On to content revisions. The back-end implementation of revisions consists of some light refactoring and a new Collection addition. Basically, I’m moving the file, filename and filetype fields from within the Content collection into the Revision collection. I’m also tacking on a contentID to provide that one-to-many relationship between content and revisions.
The front-end implementation is where it starts to get tricky. After going over the functionality of revisions with Wes, these are the changes that need to happen. The ContentRenderer component needs to be refactored into a RevisionsRenderer component. It needs to be able to render an array of revisions. The ContentDetail component routing also needs to be updated to allow for revision deep-linking, as well as substitute the Approve and Reject buttons for Void and Revise buttons for senders.
Refactoring ContentRenderer to RevisionsRenderer was easy, but I did break the beta for the first time ever by deploying in an unstable state. Need. To. Write. Tests. And. Implement. CI.
Since I’m in the refactoring zone, I refactored the server startup logic from server/main.js into /imports/startup/server/index.js.
Back to the revision implementation. Of course, I just discovered more back-end changes that need to happen. I’m referencing the content filename several times in the codebase, specifically within activity notifications in the feedback thread as well as within notification code. These need to be replaced with either the content title and/or the revision filename. Content doesn’t have a title at the moment, so I’m going to implement that first.
Lots of changes here. We need to update several email templates, notification code, activity code and data model code. This started off with the idea of one sender to one recipient with one file. We now have one sender to many recipients with many revisions of files. Managing the intricacies that get introduced by all these changes are what adds value to this platform.
I implemented action button rendering logic based on user privileges such that users that are allowed to approve/reject see approve/reject buttons and users that are allowed to void/revise see void/revise buttons. Also added a back-end method for making content void and updated the front-end to reflect void content.
Aaaaand I got into the flow and completely forgot what I’ve done the last two hours. I think I made RevisionsRenderer a carousel, with some state magic. Also refactored the Filepicker component to fire a callback if one is defined. That combined with a publication of revisions and sorted by reverse chronological order gets us a working versioning carousel.
Timing was 4h 40m and we hit our November target.
Next week:
- Move marketing pages into application
- Redesign all the things that Wes has finalized in InVision
Read the other half of this week with Wes’ VRBTM Value at Every Step | Week X where he fleshes out all of the drip campaign emails.
We’d love to hear from you…
Get in touch at Founders@vrbtm.co, talk with us on twitter @vrbtm.co, and read our story on medium.
Wes Jones is on Twitter @WesJonesCo
Nick Dandakis is on Twitter @Dandakis
