[Refactor] Recipe Schema Types

[hay-kot]

The Current Recipe type in the schema directory does a poor job of representing the actually type of a Recipe. It includes many {type} | None fields that should never actually be null for a created recipe, but because of technical debt reasons, require a nullable property which makes the generated frontend types difficult to work with and adds unnecessary null checks or wacky type casting to use properly.

More importantly, it creates distrust with the type system which I think leads to actual bugs where a developer assumes the type checker is wrong and casts to another.

I suggest we refactor the Recipe model into subtypes like RecipeSummary where they represent a subset or superset of the Recipe Representation.

My general ideas is to have

• RecipeMaybe which represents a type with nullable properties which can be used as an intermediary type that is used for Import/Export or constructing a recipe before it is saved to the database.
• RecipeOut which represents the full data transfer object of a single recipe with all fields. This will contain the least amount of nullable fields
• RecipeSummary largely similar or the same to the existing model which represents just the basic details.
• RecipeIdentifier - Not sure if this is necessary, but it could be an alternative to summary that is even slimmer and just contains the Name, Slug, and ID. Useful for a dropdown of a dropdown, or for a faster quick-search.

I think we could apply these naming conventions to other objects as well, e.g. CategoryMaybe, CategoryOut, CategorySummary, CategoryIdentifier if necessary. Specifically I am thinking in the context of search and filters where you need varying amounts of information and less is better.

[michael-genson]

I think for recipes specifically the RecipeIdentifier is a great idea. Can probably extend that to a few different schemas (e.g. schemas with extras). Amazon does something similar with Alexa lists and calls it "List Metadata":
https://developer.amazon.com/en-US/docs/alexa/list-skills/list-management-api-reference.html#get-list-metadata

For RecipeMaybe I did something sort of similar when I refactored the shopping list item schemas. I have ShoppingListItemBase with a bunch of nullables, then ShoppingListItemCreate ShoppingListItemUpdate and ShoppingListItemOut with progressively fewer nullables. Might work here too (though Recipes are a lot more complex)

[hay-kot]

I like MetaData instead of Identifier as a subtype...

Though to me RecipeIdentifier has a clearer meaning of things that identify a recipe, and RecipeMetaData is a more general term that doesn't exactly mean anything specific. We should definitely bike shed on those two options for 2-4 weeks.

I have ShoppingListItemBase with a bunch of nullables

To me, {Type}Base indicates a set of shared functionality or properties and not necessarily a type to be used outside of the package. I wouldn't really expect to use a Base type outside of

{Type}Maybe IMO gives a clearer intention of use. When I see Maybe I think - "I'm not sure what this is, but I should probably be extra careful on validation

--

To be clear, I think these are all good ideas, and I'm mostly just thinking out loud, not trying to say I or you are wrong/right. At this point I'm mostly just trying to find a direction "language" to use to make intentions clear - cause right now (like any large codebase) we don't have consistent language around the types used

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.