Page MenuHomePhabricator

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

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



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

rP Phabricator
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

epriestley created this revision.Mar 11 2019, 3:17 AM
epriestley requested review of this revision.Mar 11 2019, 3:18 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

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.

This revision was automatically updated to reflect the committed changes.