Replaces the {% float_input %} template tag with a <float-input> custom HTML element.
Better separation of front end from server, more control, so much simpler to deal with
Design language for adding recipes and ingredients as components
Clicking on a row means you want to edit that item, if you want to add as an ingredient to a recipe, you click the button with the ingredient icon
Full CRUD for all fields except owner. The API technically allows creating flags, but the front end does not (and I'm still shaky on how flags might get used so I wasn't motivated to build a combo box to deal with it).
I also made the create and update operations for the nested recipe serializer atomic. This was necessary because an error halfway through the process could really throw some muck into your db.
Future considerations not part of this MR
Better search is a must, right now you can only search by name.
Nutrition is the goal, so nutrition should be able to take front and center. The interface is full right now so I'm thinking maybe a button in the top right to enter 'Focus on Nutrition' mode, that hides all fields not related to nutrition and provides a graph so that you can visualize what components contribute what nutrition. Enabling you to build recipes, and pick servings to hit your targets
The recipe manager and ingredient manager are sooooo similar. The only thing keeping them as separate pages is I haven't figured out a good way to get both recipes and ingredients together in one table. If there was a "Components" api, both pages could easily be merged, and the 2 tables on the recipe manager could become one table. Working with 2 API's is entirely doable though.
Next step is probably either the diary or targets, and the next UI enhancement is probably going to be charts or graphs
As promised, the recipe manager.
<float-input>custom HTML element.Future considerations not part of this MR