Or even tags might make sense here, instead of even single items. That way, if you were planning a party, you could set a guest list and pull the common tags for the people coming (hypothetical scenario / feature).

I'm looking at an interesting first issue to try and fix. Is the idea to have the Food section work like the Pets or Contact info sections (but probably without a type field)?

That seems like a reasonable idea!

Alright, my idea: food preferences is a separate table, á la pets. A preference is combination of a type (with icon) and a text line. Preference type are:

• 👍 like
• 👎 dislike
• 🚫 allergic

This list can be extended and the preference type can be null.

The change would consist of:

• Database migration:
  • New database tables food_preferences and food_preference_types.
  • Insert food preference types.
  • Split current contact field food_preferences by newline and insert as food_preference records without type.
  • Remove food_preference field from contact.
• Change food preferences frontend component to work just like pets.

Suggestions for better naming and other ideas very welcome.

If this sounds good I'll create a PR.