How to dispatch model data back to specific Mediator?

[Andy Riedel]

I have what seems like a pretty standard use case for which I haven't been able to find any solution in any of the Strange docs or forums.

How are you supposed to return data from a model back to a specific Mediator?

I have multiple mediators of the same type. Each of them needs to be able to dispatch a Signal/Command in order to retrieve some data they need. According to all the documentation I've read,Commands are able to fetch data from Models but then they need to dispatch a new Signal to return the data to the Mediator. The problem I'm encountering is EVERY Mediator of the same type is receiving the data. Whether I use the [ListensTo] attribute or manually add/remove the necessary listener.

My workaround has been to pass a lambda function as a parameter of the Signal/Command so the Command can call back to the specific Mediator that supplied the lambda function in the Signal dispatch.

What is the standard practice in Strange to address this and why isn't it documented anywhere? I appreciate the desire to keep everything decoupled but this seems like a pretty standard user case.

Thanks for any help anyone can provide!

Andy

[wcorwin]

The problem I'm encountering is EVERY Mediator of the same type is receiving the data.

This suggests you're creating a Mediator for every type of whatever you're working with. Probably a Collection of some kind of Models. It's possible you need that granularity, but if not, I would dial it back a bit.

Instead of mediating TankView with TankMediator, make a TanksView and TanksMediator that has refs to the views and can easily direct dispatched data by id.

If this is way off base, I'd need a little more information. It sounds like you're upset about the basic use case of a Signal, which is that everything can listen to it.

[Andy Riedel]

Thank you for the quick reply.  

Maybe I can clarify. I don’t have an issue with the basic use case of Signals allowing anyone to listen nor do I have a too-many-mediators problem. My specific question is how to provide Mediator-specific data from a Model without having to broadcast the data to every Mediator of the same type.

I have an implementation where I have a model that stores a set of Unity camera instances. In my Mediator OnRegister, I broadcast a Signal in order to retrieve one of these camera instances. the executed Command accesses the Model, finds the proper Camera instance and dispatches another Signal with the Camera instance.

If I use the ListensTo attribute in my Mediator, every Mediator instance of this type will receive this camera instance even if they already dispatched their own signal and received a camera instance already. While I don’t have a lot of these Mediator instances (about 5-10 at a time), it just seems inefficient for every Mediator instance to receive a new camera instance and have to process whether they are the designated target for it. 

Is there an easier way to return model data back to just one of these Mediator instances? I suppose I could manually add/remove the listener once the camera instance has been supplied or I could use the lambda function hack to get the data back to just the one Mediator I want?

As for your suggestion about using a single Mediator to mediate a set of Views, what’s the best way to provide the refs of multiple views to the Mediator? My views are instantiated dynamically at runtime. Can Mediators be singletons or would the Mediator inject a singleton Model that is loaded with each View ref and access it directly?

Thank you for your help! 

On Aug 12, 2019, at 8:00 PM, wcorwin <wco...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "StrangeIoC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to strangeioc+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/strangeioc/0dca9b01-7948-48db-8f53-5e93e6d60948%40googlegroups.com.

[wcorwin]

For starters, I think you're maybe worrying a bit much about efficiency. Gating on an id in a handful of mediators is negligible work, so I wouldn't get too bothered by it. 

If you really can't stand the way the code looks, you could just use a standard double callback here. Depending on how your logic works, a Promise could work great, as well.

If none of this works, it's probably time to supply some code and I'll see what I can do. I've been deep in ECS brain space, though!