While the CAPNote model has sub-models for practices and issues embedded it in, they aren't stored in separate collections. This is great for not having to write a lot more fetching and updating code, but annoying when different parts of the interface need the same piece that can change (e.g., referencing an issue with the issue content [like plans] changing).
Probably better to have 3 data collections: CAPNote, issues, and practices, with the latter two referred to using ObjectIDs. Then, by using state hooks, we can track changes to each of these collections and also have separate saving code for each (the useEffect(...) in pages)
While the CAPNote model has sub-models for practices and issues embedded it in, they aren't stored in separate collections. This is great for not having to write a lot more fetching and updating code, but annoying when different parts of the interface need the same piece that can change (e.g., referencing an issue with the issue content [like plans] changing).
Probably better to have 3 data collections: CAPNote, issues, and practices, with the latter two referred to using ObjectIDs. Then, by using state hooks, we can track changes to each of these collections and also have separate saving code for each (the
useEffect(...)in pages)