Nutrition Solver — The Adventure Continues
Vuetify, JavaScript, V-Data-Table, And PR Rejects
Last time I took a look at a project Smack was throwing up called “Nutrition Solver,” which he wrote simply to build recipes and calculate macros. I thought this would be a great opportunity to replicate whatever he had in Vuetify, since it seemed like a perfect example of a time when we DIDN’T need one. There would be way more dependencies. There would be way more code. The one advantage, if there was any, would be ease of use and speed…and even that may have been irrelevant, considering how much time I spent getting up to date with Vuetify3.
Not too much to report this time…the v-data-table, in spite of what their documentation says, does not seem to be supported yet in Vuetify 3. My workaround was using Vuetify Labs, which they very clearly state they will not support.
Needless to say, my pull request was rejected.
Edit Button In V-Data-Table
One thing v-data-table comes with out of the box is the ability to search all rows and columns, and see the table automatically shrink or expand accordingly. This was neat…I guess…but Smack has updated his vanilla HTML/CSS/JavaScript app, and it has become clear that this is not what he had in mind.
Instead, what you are meant to do with the search bar, I now realize, is input some ingredient to automatically add to your table. Smack prepopulated maybe a dozen values itself, but it seems like a good opportunity to link my version to someone else’s API.
What I did this time around was work on the “edit” button.
Someone threw up this CodePen — they go by the username Jayesh.
Their edit, save, and delete operations work really well. What I wanted to do was track sum, and it just was not working. When the user edited something, it would simply copy in both values, so editing 50 to 51 would get you 101 instead of simply changing to 51.
A trivial solution would have been to re-calculate sums from all rows in a column each time. This sounded non-ideal to me, no matter how small the actual processing required is…it would just be bad code. Instead, if there was any way to preserve a previous value and simply subtract the old ones before adding the new, that would avoid unnecessary calculations. In other words, if you were to edit a 5 to a 6, I would only want to add 1 to the total sum…no need to re-calculate all values in a given column.
Long story short, I spent quite a while on a red herring. I was trying to check this in the editItem function, and I just was not sure why I could not use this method to check the previous value against the one they were editing.
The answer is kind of simple. When a user clicks the “edit” button, they see the menu for “edit item.” This is not the time to re-calculate sums. The time to re-calculate sums is when the user hits “save,” which is also when the user has access to both the previous and new, edited values.
In short, when the user is editing an existing entry, subtract the previous/deleted values and then add those of the new one. If it is a new entry, push it and continue to add…but do not attempt to subtract first.
The assign operation is interesting to me. Its parameters are (target, source), making it somewhat reminiscent of C’s memcpy function. I wondered why Jayesh was using was using the empty {} as the first parameter in Object.assign, for his (or her) edit function, and the answer is here.
Possible next steps:
- Pull from API
- Frontend unit tests
- Expand to customized server side
- Add database
Closing Thoughts
I thought it was inspiring to see a video by this guy who, instead of simply grinding LeetCode, spent time trying to actually build a browser extension to help with LeetCode.
