Add a "WorkboardCardTemplate" class to make workboard client code easier to reason about
ClosedPublic
Actions

Authored by epriestley on Mar 11 2019, 3:17 AM.

Details

Reviewers

amckinley

Commits

rP7d849afd16c5: Add a "WorkboardCardTemplate" class to make workboard client code easier to…

Summary

Depends on D20266. Boards currently have several whateverMap<cardPHID => stuff> properties, but we can just move these all down into a CardTemplate, similar to the recently introduced HeaderTemplate.

The CardTemplate holds all the global information for a card, and then Card is specific for a particular copy in a column. Today, each CardTemplate has one Card, but a CardTemplate may have more than one card in the future (when we add subproject columns).

Test Plan

Viewed workboards in different sort orders and dragged stuff around, grepped for all affected symbols.

Diff Detail

Repository

rP Phabricator

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

epriestley created this revision.Mar 11 2019, 3:17 AM

Harbormaster completed remote builds in B22245: Diff 48382.Mar 11 2019, 3:18 AM

epriestley requested review of this revision.Mar 11 2019, 3:18 AM

epriestley added a child revision: D20269: Modularize workboard column orders.Mar 11 2019, 4:56 AM

amckinley edited the summary of this revision. (Show Details)Mar 12 2019, 6:58 PM

amckinley accepted this revision.Mar 12 2019, 7:05 PM

This revision is now accepted and ready to land.Mar 12 2019, 7:05 PM

epriestley added inline comments.Mar 12 2019, 8:01 PM

webroot/rsrc/js/application/projects/WorkboardBoard.js
314	This might be a behavioral change / wrong, but I couldn't figure out why this check existed, and I've touched most of this code now in implementing the new "Group By Header" stuff. Generally, all the code handles updates to objects it already knows about gracefully, and the obvious cases (adding a new card / editing an existing card) appear to work fine, so I suspect this wasn't meaningful.