Page MenuHomePhabricator

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

Authored by epriestley on Mon, Mar 11, 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.Mon, Mar 11, 3:17 AM
epriestley requested review of this revision.Mon, Mar 11, 3:18 AM
amckinley edited the summary of this revision. (Show Details)Tue, Mar 12, 6:58 PM
amckinley accepted this revision.Tue, Mar 12, 7:05 PM
This revision is now accepted and ready to land.Tue, Mar 12, 7:05 PM
epriestley added inline comments.Tue, Mar 12, 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.