Question: 'Back propogation' from values about gjallarhorn HOT 5 CLOSED

No. At one point, I had implemented something similar, but it tends to lead to issues, so I decided to abandon it. Specifically, this tended to break the weak referencing schemes that I currently use, though I do think it could be done.

I've found that it's often conceptually nicer to have "mutations" back to the source work through a separate channel (such as using observable streams to push back changes).

What is the use case or need here? There may be an easy way to do it, or I could be convinced to implement this.

from gjallarhorn.

A use case for mine is this:
Say we had a value stored on the disk, in some human-readable format.
This has an in-memory representation of type A.
value of type B is created in a linked manner from the value.

Now we have two cases where we would want to propagate:

• if (B) is updated, the disk-backing value should also change (A).
• if the disk-backing value is changed, then B should reflect this.

The trick is using the library makes this largely transparent, provided the mapping is set up correctly.

Hopefully that's a bit more clear?

from gjallarhorn.

Yes - there's a lot of complexity around the edges when trying to do this correctly, which was part of why I abandoned it.

Currently, the approach we use in the framework built on top of Gjallarhorn would be to have a signal mapping from B (on disk) to A. Instead of mutating A, you'd create some message to update B, which causes the update and is immediately reflected again in A. The library makes this fairly easy to do - and it keeps things very clean.

from gjallarhorn.

Thanks for the super prompt answers. Yeah, I use graph painting to do the propagations properly.

Can you show an example of how this code would look.
How do you avoid cyclic propagations?

from gjallarhorn.

Can you show an example of how this code would look.
Take a look at some of the UI framework samples - https://github.com/ReedCopsey/Gjallarhorn.Bindable/blob/master/samples/ElmInspiredOne/ElmInspiredOne/Program.fs

That should give you an idea of the basic concept. You can drill into it, or if you need it, I'd be happy to discuss how the "guts" of it work, but it's fairly simple to setup.

How do you avoid cyclic propagations?

Effectively, propogation is only one way - "edits" on the front (A) are sent as messages to update the backend (B) , and don't actually change A. A then automatically gets the new value reflected. Signals, in the default implementation, only propagate changes if the value itself changes, so cyclic issues don't happen.

from gjallarhorn.