Looking for thoughts from people who know more about writing apps with databases than me (so probably a lot of people).
If you're viewing a list of items, and you want to split the code for individual items into its own function viewItem, you have two choices. Either viewItem accepts an ID for the item to show, and then the function gets the item's fields from the database based on the ID. Or viewItem accepts a list of fields, and those are queried by the caller function viewList. I've written these two options in the embedded image. (I'm using SQL and React as examples, but it's not about those technologies specifically)
The problem with the first option is that it's making an extra query for each item, which is pretty expensive. The nice thing is that there's less coupling: if you change what you want to render (e.g., add or remove a field), there's only one place to change. So, to me this feels like the best option, if only it were more efficient.
I'd love to have my lunch and eat it---that the fields I query in viewItem would somehow affect the query in the parent. Does anyone have ideas about this?
=> More informations about this toot | View the thread | More toots from xavier@sunny.garden
text/geminiThis content has been proxied by September (3851b).