Refactor the update management

We should evaluate which one of the suggestions is the cleanest and refactor to implement it:

I'd rather suggest to put these in a dedicated function to improve readability. Instead of calling the asynchronous task, you may want to call this.requestUpdate() (Lit doc), this way Lit will handle both the task & rendering as required, eg. when a user call 2 times in a row this event, it'll only be rendered once.

Also notice that you don't need this event-based behaviour to handle reactivity manually, you can use boilerplate's helpers, like setupCacheInvalidation which is based on keywords on the url received from a store's save event. This way it'll also work if independent component handle those same datas. With this helper, it's part of the URL. By default, the component based on the boilerplate already look for its own dataSrc-based save event. But sometimes, you want to update the component when something unrelated happens, like: I'm displaying http://server/objects/1/ When something happen to http://server/potatoes/ or http://server/potatoes/anything/, I'd like to refresh my data source Then, in this scenarii, you can setup this setupCacheInvalidation on the potatoes keyword. Whenever a save event happen with a potatoes in its @id/id, it'll trigger an update. You can also use setupCacheOnResourceReady which will behave on keywords too, but on the resourceReady event instead of the save one.