Inconsistent card face when toggling between Pattern Types

[cwatsonc]

Describe the bug
When card is opened in storybook and the controls are toggled between Tarot -> Franconian the card is left blank; when the card is toggled between Skat -> Franconian the card face is misaligned. I suppose one could argue this use case is out-of-scope -- but we're the common code so we don't know all the described uses.

UPDATE: This behavior appears to be isolated to "Canvas" and not "Docs" view.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'docs:games shared : components: cards : card'
2. Click on the tab for 'canvas'.
3. Click on 'controls tab and toggle the Pattern radio buttons'
4. When moving between Tarot -> Franconian the card face is empty
5. When moving between Skat -> Franconian the card face is misaligned with the master sheet of cards.
6. If you refresh the browser while on Franconian the face is populated and will work correctly until a refresh on Tarot.
7. If you use the Docs tab this behavior is absent (makes me believe it's a sb defect)

Expected behavior
Moving between these types should always yield a valid face

Video
Demonstration of defect using storybook
Demo on Chrome, Safari, MacOS Big Sur
Desktop (please complete the following information):

• OS: [MacOS Big Sur]
• Browser [Safari 15.0, Chrome 94.0.4606.81]
• Version [] <--- is this supposed to be game version?

Additional context
Really suspecting this is a regression on sb@6.0.22 where I don't see the behavior in PRD.

Now present in PRD since PR #991

[tuxor1337]

I can't reproduce this in Firefox (93.0) on Linux (Fedora 34) with the latest master branch. I currently don't have any other browser to check.

[cwatsonc]

I have both Intel and M1 architectures to test this. Please look at this reproduction of the defect on Chrome and Safari across multiple stories. Can we tag this build master at HEAD? I will open a defect with Storybook where I think the underlying issues occur.

video repro defect

[cwatsonc]

I can't reproduce this in Firefox (93.0) on Linux (Fedora 34) with the latest master branch. I currently don't have any other browser to check.

@tuxor1337 Can you please retest on PRD to see if Firefox still is consistent with expected behavior? The behavior is confined to "Canvas" view using the "Controls" tab.

[tuxor1337]

I now had a look at your stories file and am wondering how this could work when I tested it yesterday. You seem to use CardColor.Clubs with all three patterns. This is impossible, since not all patterns support all CardColor values:

• Pattern.Skat supports [CardColor.Diamonds, CardColor.Hearts, CardColor.Spades, CardColor.Clubs],
• Pattern.Tarot supports [CardColor.Clubs, CardColor.Diamonds, CardColor.Spades, CardColor.Hearts, CardColor.Trumps, CardColor.Excuse],
• Pattern.Franconian supports [CardColor.Schell, CardColor.Herz, CardColor.Gras, CardColor.Eichel].

For other values of CardColor, you will get undefined behavior. Would you prefer to have the code raise an exception when an unsupported CardColor is given? Or should there rather be a fallback (like, a blank card)?

[cwatsonc]

Not sure what the good fallback behavior is -- usually in js try to message rather than throw an exception -- maybe the type checking should be stronger and only valid values available through the API. There's a strategy to the sb "controls" behavior when a complex object is the parameter -- I glossed over it to get the behaviors working (in their limited fashion). Now that we have a better understanding perhaps you will find some value in my start and take up the finer points.

Where would I find the range of values prescribed by your API? I was seeing the strange behavior but don't have time to reverse engineer your code... provide some nudges and maybe the community can help.

thanks for your help -- I need to go face the sb community who received my reports the issues were with their updates -- seems very odd that it degrades so well under their "docs" framework and so poorly under their "canvas" api -- if you can suss out that answer they probably would be happy to know if we've found a bug. -- have a great weekend @tuxor1337 !

[tuxor1337]

Since this was undefined behavior, I have no reason to assume that there was a bug on behalf of the storybook library.

I fixed this issue in #995 by having an error message appear on the card whenever an unsupported combination of Pattern and CardColor is specified.