Mirroring without effects

[polux]

I think it would be nice to have an even less mirroring that would listen to the app.model signal for changes and apply diffs to the database. Very much like virtual dom and redrawing. That way the update function would be reusable on a non-mirrored model and it would not return effects, which would make it much easier to test.

What do you think?

[ThomasWeiser]

Would be an interesting approach. Do you have a certain use case in mind?

Let me see if I understand you correctly:

Current elmfire-extra's setting goes like this: Firebase data is mirrored locally; local writes are redirected to Firebase (and eventually appear in the local mirror). Your approach of mirroring goes in the opposite direction: The local model is mirrored at a Firebase.

Some thoughts:

1. How to perform diffing the local model (probably a Dict) efficiently? Maybe through some custom implementation of Dict or Array? Or just accept the cost?
2. Presumably the app also wants to follow Firebase updates written by other clients. Doesn't we then reintroduce a form of two-way data-binding with some unwanted complexities?

[polux]

Your approach of mirroring goes in the opposite direction: The local model is mirrored at a Firebase.

Yes. Actually my idea was that both would be a mirror of each other.

How to perform diffing the local model (probably a Dict) efficiently? Maybe through some custom implementation of Dict or Array? Or just accept the cost?

I briefly looked at react's diffing algorithm and it looks like they get away with naive diffing. For the app I'm wriging that would probably be sufficient, but to be fair resubmitting the whole state would probably be fast enough since that app's state is so small.

Presumably the app also wants to follow Firebase updates written by other clients.

Yes, that's what I meant by "would be a mirror of each other".

Doesn't we then reintroduce a form of two-way data-binding with some unwanted complexities?

That is a good point! It is actually very similar to the concerns raised in the elm-route-hash documentation. Maybe the same kind of tricks could be used here.

But I'm not even sure that is needed: I can't come up with an example scenario where this two-way binding could trigger a loop other than by having a "bug" in the logic implemented by the clients where a change by one client triggers a change by another client that leads to the state that triggered the first change. But that can already happen today with effects. Maybe I'm missing something though: do you have an example in mind of something that could go wrong with this two-way binding?

[polux]

Sorry, I forgot to respond to

Do you have a certain use case in mind?

I don't have a particular use case in mind: I just starting using elmfire-extra (thanks by the way!) for a personal project. The app allows participants to vote on some question and then when everyone has voted, the results of the vote are revealed. The app remembers past votes. But that is kind of irrelevant to this feature request.

My main concern with effects is that, as far as I understand at least, they are black boxes for the caller. That makes it harder to test your code. Also the proposed design would allow the same app to work with or without firebase.