Refresh related entries on changes

[rmunn]

Fixes #1333.

One flaw in this design is that the $entries list in viewer/src/ProjectView.svelte comes from a derived, meaning it's read-only, so the only way to refresh an entry is to refresh the entire list. That's why I've left in a console.log('TODO: ...') line: so that if we decide to merge this as-is despite this flaw, we have an annoying console message nagging at us to find a better solution. I might want to work with Tim on fixing this, since it might involve a major rewrite to how we store entries. (Or we might decide it's not worth fixing, and we're okay with refreshing the entire entries list every time an entry's list of components or complex forms is changed).

Other than that, this works as desired: when you add a complex form or a component, the related entry is refreshed. When you delete a complex form or a component, the related entry is also refreshed.

[github-actions]

UI unit Tests

12 tests   12 ✅  0s ⏱️
 4 suites   0 💤
 1 files     0 ❌

Results for commit 2376f9a.

♻️ This comment has been updated with latest results.

[github-actions]

C# Unit Tests

104 tests   104 ✅  5s ⏱️
 16 suites    0 💤
  1 files      0 ❌

Results for commit 2376f9a.

♻️ This comment has been updated with latest results.

[rmunn]

@hahn-kev - Although this is marked as draft, it's fully functional except for the two flaws I mentioned in the description, one of which I'm going to fix tomorrow morning. So this isn't going to change much, and it should be suitable for a review right now.

[rmunn]

Managed to fix the second flaw I mentioned in the description before going home for the evening, so I've updated the description to remove any mention of that second flaw (see edit history if you want to see it). So this PR has come as far as I'm going to be able to take it, unless we decide to make major structural changes to how we store entries so that we can update a selected subset.

So now I'm going to take this out of draft status and mark it as ready for review.

[hahn-kev]

for the issue of not being able to update a single entry, take a look at the onEntryUpdated callback on line 49 of ProjectView.svelte you would just need to call lexboxApi.getEntry then use the logic in onEntryUpdated to update the entries list.

That said, considering we have all the pluming for onEntryUpdated I'm not sure we even should be doing this in the front end. We could push the changes from the backend, it doesn't work this way today, but as an example inside of CreateComplexFormComponent we could notify that 2 entries were changed. That said it does have a number of downsides, the main one being that the said method should notify that both entries were changed, and if CreateComplexFormComponent is being called from UpdateEntry it's possible that there's a number of other changes, meaning we might end up notifying that the same entry changed multiple times, there are simple ways to mitigate that with the reactive model we're using in C#, but I'm not sure I want to go down that road.

I bring this up because I don't really like bringing back change detection code inside Editor.svelte we were doing that before and decided to shift that to the backend, now we just call update(before, after). That's going to set us down the path of duplicating checks for changes and bugs will come up from those getting out of sync. My above suggestion is a way to avoid them getting out of sync, but has other caveats. Alternitvly we could shift the refresh notification to be inside ComplexForms and ComplexFormComponents as it knows what data was just changed, so it could emit a refreshEntries event at the same time it emits a change. This would also be tricky as we would run into race conditions between the save and refresh events where the data hasn't actually been changed server side so the refresh would get the old data. State management, yaya.

[myieye]

@rmunn only _entries is derived. But we simply assign that reactivly to entries, which is writable.

I think I like the idea of moving the related entry change detection to the backend. 😬

But, yeah...it's the first time we'll start shooting off events without exactly knowing what context we're in, so it's a new concept.
Theoretically, the code in EntrySync.cs knows if we need to notify about the component changing or the complex-form changing, so that we wouldn't have to always notify about both.
With regards to duplicate notifications. That doesn't seem to critical to me. It might actually even be a feature: the UI is notified about some changes sooner than it might be otherwise 🤷.
If we were to try to trigger the events from EntrySync.cs I'm not sure exactly how we'd want to go about doing that.