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 ec39418.

♻️ This comment has been updated with latest results.

[github-actions]

C# Unit Tests

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

Results for commit 9255256. ± Comparison against base commit 00d37fd.

♻️ 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.

[hahn-kev]

yeah I wouldn't trigger the events from inside EntrySync, I would trigger them inside CrdtMiniLcmApi, so EntrySync calls CreateComplexFormComponent and we would notify the client that both those entries changed after that was done.

[rmunn]

Okay, I'll rewrite this to move the "entry changed" notification to the backend. Here's my summary of the design, please speak up if it looks like I'm misunderstanding something:

• We won't create a new EntriesUpdated event for this, because the number of entries involved is small (usually only 2 or 3 componens per complex form). If in the future we want to be able to notify clients that these 100 entries all changed at once (some kind of bulk-edit tool), we can add EntriesUpdated at that time, but in the meantime YAGNI so we'll just fire two or three EntryChanged events.
  • Currently the frontend will fire a store update for the whole $entries store for each EntryUpdated event, but that will probably change once we move to Svelte 5 where state is more granular, so we don't need to optimize that right now.
• The CreateComplexFormComponent method will be responsible for calling NotifyEntryUpdated for the components that changed.
• DeleteComplexFormComponent will likewise need to call NotifyEntryUpdated for the entries that used to be involved in the deleted component.

One thing I don't know yet is how CrdtMiniLcmApi should get hold of an instance of CrdtMiniLcmApiHub to call NotifyEntryUpdated. That's a part of the system whose design I haven't yet studied. I'll look into that and see if I can wrap my head around it myself, or if I need to ask Kevin some questions later.

[rmunn]

No, CrdtMiniLcmApi shouldn't be referencing the hub, because the hub references CrdtMiniLcmApi. Can't have a circular dependency chain. So I need to rethink how the code in CrdtMiniLcmApi is going to fire off the EntryUpdated event.

[hahn-kev]

Take a look at ChangeEventBus that's where you notify changes from, everything else listens to that for changes. Also remember that Hub you were looking at is in the Web project, meaning it won't work for the Maui version

[rmunn]

Rebased on top of most recent develop branch.

[rmunn]

yeah I wouldn't trigger the events from inside EntrySync, I would trigger them inside CrdtMiniLcmApi, so EntrySync calls CreateComplexFormComponent and we would notify the client that both those entries changed after that was done.

Take a look at ChangeEventBus that's where you notify changes from, everything else listens to that for changes. Also remember that Hub you were looking at is in the Web project, meaning it won't work for the Maui version

I've been looking at this code for a while now, and unless I'm completely blind and missing something obvious, these two suggestions aren't both possible.

CrdtMiniLcmApi is in the LcmCrdt project, which has minimal dependencies; in particular, it doesn't have ChangeEventBus available to it, because ChangeEventBus is in FwLiteShared. FwLiteShared depends on LcmCrdt, so LcmCrdt can't depend on FwLiteShared, so there's no way to make ChangeEventBus available to CrdtMiniLcmApi in order to use it.

Instead, from what I can see, we would need to create a new method in IMiniLcmWriteApi called NotifyEntryChanged (or something), and then both FwLiteWeb and FwLiteMaui would be set up to listen to those EntryChanged notifications and pass them on to the ChangeEventBus.

... Or something along those lines, anyway. I think I want to discuss this before finalizing on a design. So I'm going to put this PR on hold for now and go work on something else.

[hahn-kev]

yeah I didn't expect it to be easy, I'm not really sure what the best way is to do it right now, I've got a bunch of ideas but none of them are great

[rmunn]

Restarting this PR. I'm going to abandon this approach and start the branch over from scratch. To avoid losing any work, I've saved commit ec39418 in a branch called feat/old-approach-related-entries-should-refresh-on-changes and pushed that branch without a PR. (Click here to view that branch if you need to). My next push will be a force push that is not a rebase.

[rmunn]

Rebasing on top of #1461 right now because I'm about to touch some of the same files, and if I rebase now I'll end up with a lot fewer merge conflicts in the future.