fix(replies): refresh replies when selection date is changed

[mforesti]

No description provided.

[cloudflare-workers-and-pages]

Deploying appforit with    Cloudflare Pages

Latest commit:	ff146bd
Status:	✅  Deploy successful!
Preview URL:	https://4c562439.appforit.pages.dev
Branch Preview URL:	https://49-replies-are-not-reloaded.appforit.pages.dev

View logs

[borgoat]

I don't understand, we need to reload the whole group whenever the date changes?

[mforesti]

I don't understand, we need to reload the whole group whenever the date changes?

No, we do not, but that's a quick fix, considering the following:

• we do not have much time
• the selectors need to be refactored and memoized
• reloading the group is not (yet) expensive with respect to performance and data

[borgoat]

No I mean it's fine that we do the query per se, I do not understand what is the side effect? Is it reloading the replies?
And if so, can't we just reload the replies?

[mforesti]

No I mean it's fine that we do the query per se, I do not understand what is the side effect? Is it reloading the replies? And if so, can't we just reload the replies?

Unfortunately, there are many needed side effects:

• Schedules
• Replies
• Default replies

Therefore, instead of repeating/amending every side effect with a new action, it felt quicker to trigger the reload of the group. I am not fond of action reuse, either. I just wanted to solve it quickly and tackle the whole construct at another time and focus on the next issue for the beta release.

[borgoat]

Hmm fair enough I'm not really sure reloading default replies and schedules should be needed, but maybe I'm missing something or there are other bugs somewhere... conceptually the idea of schedules and default replies should be that there are very few of them, potentially they are even cached. While replies of course need only be loaded for the specific instances of schedules one is looking at (so yes on date change they MUST be reloaded)

Anyway we can keep it this way now, and think about it later .. an idea I had anyway was to use this new layer for persistence that should simplify custom code in repositories a lot https://getdutchie.github.io/brick/