You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
According to http://schema.org/Recipe definition, recipe instructions may be either a block of text or a list. Same thing when it comes to ingredients. However Hangry always returns an array of strings for ingredients and string for instructions, therefore it loses important piece of information.
Fortunately when it comes to instructions, the loss is easy to revert. Instructions are typically joined with "\n" and I can split this string to get original list. It doesn't seem right though, it's actually parsing the output of parser, I guess Hangry should do that.
When it comes to ingredients, it's much worse. For recipes which describe the ingredients as a block of text, this field will be usually blank. And modifying Hangry so that it returns one-item-long array doesn't seem right too.
In my opinion, Hangry's #instructions should return an array of strings if given recipe differentiate steps, and string otherwise. Similarly #ingredients should not be guaranteed to be an array. In Ruby it's not uncommon that class of some method's return value depends on situation.
I can implement it tomorrow, but it would be a breaking change, therefore I wanted to consult the interfaces before I start.
Alternatively, another methods #instructions_list, #ingredients_list, #instructions_text and #ingredients_text could be implemented. The "list" methods would return nil when only plain text is available. This approach does not introduce a breaking change, on the other hand provide 6 methods to access these two fields can be pretty confusing I think. Perhaps #instructions and #ingredients should be deprecated then.
The text was updated successfully, but these errors were encountered:
According to http://schema.org/Recipe definition, recipe instructions may be either a block of text or a list. Same thing when it comes to ingredients. However Hangry always returns an array of strings for ingredients and string for instructions, therefore it loses important piece of information.
Fortunately when it comes to instructions, the loss is easy to revert. Instructions are typically joined with
"\n"
and I can split this string to get original list. It doesn't seem right though, it's actually parsing the output of parser, I guess Hangry should do that.When it comes to ingredients, it's much worse. For recipes which describe the ingredients as a block of text, this field will be usually blank. And modifying Hangry so that it returns one-item-long array doesn't seem right too.
In my opinion, Hangry's
#instructions
should return an array of strings if given recipe differentiate steps, and string otherwise. Similarly#ingredients
should not be guaranteed to be an array. In Ruby it's not uncommon that class of some method's return value depends on situation.I can implement it tomorrow, but it would be a breaking change, therefore I wanted to consult the interfaces before I start.
Alternatively, another methods
#instructions_list
,#ingredients_list
,#instructions_text
and#ingredients_text
could be implemented. The "list" methods would returnnil
when only plain text is available. This approach does not introduce a breaking change, on the other hand provide 6 methods to access these two fields can be pretty confusing I think. Perhaps#instructions
and#ingredients
should be deprecated then.The text was updated successfully, but these errors were encountered: