On our UI, we are presenting the user his saved credit cards as a list of Card components, each saved card represented as a card. The user can save up to 5 cards which will be presented in two rows, as shown in mock:
I now want to add the option to edit a credit card which includes the following options:
On the card, there would be an "edit" option which will flip the card from view mode to edit mode. In this case, I'm facing a conflict. On one hand, I know that cards are mainly used for view mode and maybe some very few small actions. On the other hand, it's kind of weird to me that the card now also becomes a form. I'm not sure the user expect it to behave in this way. moreover, the form looks too compressed since we kept the size the same as in View mode.
I didn't find any information regarding Card component as an edit mode.
I guess my question is if this behavior doesn't validate the Card definition and whether or not the user expects to this kind of behavior. Any other suggestions?
I would say no. Cards are used to display elements with different content. When you want to edit the card content it is more convenient to do so in an appropriate layout.
There is no need to relate the Input view with the Output view in this case.
I believe that what you have is a Grid with tiles (used for items with the same content) rather than cards.
In your case I suggest using a Full screen dialog (or a normal dialog) for the editing view:
You can check Google Keep app for reference, where the view mode uses cards but to edit a card you are taken to an editor.
I don't see any reason why not.
These (material) design guidelines are what they are, guidelines, not rules. The only reason to follow guidelines is because they often follow user convention (that what the user is used to and expects).
I know that cards are mainly used for view mode
You say it yourself, mainly.
In case of Google's Material Design, it's not even excluded a card can contain a form.
Cards display content composed of different elements whose size or supported actions vary.
Input fields and switches are content too.
In your case I would say it's great to keep in on the back of the card, because it keeps the user in context. It's clear which card is being edited. Is it what the user expects? Probably not, because I haven't seen this kind of thing in the wild so I'm expecting a lot of other users haven't therefor they can't expect it. But the animation visually communicates in a clear matter what is happening. I'm willing to bet not one user will be confused, about what happens. They might even be delighted, because of the animation and the fact that they're not pogosticking between a view with the cards and a view with just the editing options.