Channels do really not work well with Reactive.Unit out of the box, since the channel’s inherent change check optimization does not play well with Unit
Demos don’t translate from other types to Unit.
generic usecases of channels have to change in case of type unit (just happened to me when i had to change some imgui from toggle button = boolean to button = unit
even though i’m aware of the special case of a Unit message i consistently stumble over it. issue is, one has to remember when ‘chaining’ unit messages to always force them. either SetValue, or EnsureValue (force), Consume and Merge push eagerly etc.
i’d nearly call it a bug, at least a serious design flaw. since Unit messages are not some esoteric special case but quite integral due to the imgui.
were channels not still labelled experimental? maybe it’s not too late to do some breaking changes…
possible solutions come to my mind:
change Unit type to a unique instance to trigger channels change check if it’s actually a new message. pro: no need to change any other channel nodes + one could actually work with a spread of units and know which changed, cons: introduces friction when wrapping observables where unit is a basis type.
split channel nodes into safe/simple and advanced nodes, i don’t mean different versions. more like we already have it with EnforceValue (safe) and SetValue (guards off). so the observables conversions are imho more advanced, so get rid of internal change check.
Merge has two flavours anyways. the one with optional could use setvalue instead of EnsureValue internally.
extend channels with properties like ValueChanged & MessageReceived
besides the all the ranting channels are a refreshing tool separate view from state/logic when used with other simple types. cheers @gregsn i guess
I’d use integers that count up for each click instead of Unit. You can do that yourself as well, but having bang buttons send changing integers directly would also help to understand how many clicks happened between frames without extra patching.
Had another look at this: shying away from merging this back right away because of this being a breaking change, but did change the type from Unit to Bang with the main benefit, that equality checks typically return false, thus most operators work as expected.
maybe not necessary, if Bang is used everywhere. I made buttons use them, needs more testing.
ValueChanged being a process node with an Update call, outputting true outof the perspective of that patch - e.g. since last looked at by this “observer”? MessageReceived along those lines?
didn’t have the chance to compile and test yet.
first question would be, how does chaining work (consume / merge) with an increment.
the usecase from my last project was a couple of reset something buttons and one reset all. the all trigger would be consumed by the individual ones which each did their thing.
would a consumed bang have the same increment as the source or just also increment it’s own counter?
I made a special build to try it out.
Merge should propagate events as each Bang is different. The increment / integer value is not perceivable from the outside. It’s better to think of each bang to be just some unique thing.
Let’s test it out and take it from there.
Hey!
I didn’t merge back the breaking change as there was no feedback on my proposed solution. Does the proposed solution work for you? Did you try the build?
I suggest waiting for more upvotes before committing to the solution that comes with a breaking change.
Ok?
I would suggest to rename Trigger to Create, or add a Create to Bang. Pipeline feels like if it would expect new reference, and Create is likely the most intuitive thing users would look for.
So the route issue is:
Each Select (ByPath) creates an anonymous channel and in your example, you end up having several different channels responsible for the same property. They get synced behind the scenes and for the particular case of Unit the syncing logic fails as there is nothing to do.
So currently I see these two main routes to address the problem.
Ensure that there is always only one Channel per Property. This could be done via global channels. But there could be other ways of doing it.
Avoid Bangs in those data types.
Model Events via Bang datatype. This way you don’t get forced into some refactoring you didn’t ask for. It might break some existing patches though. All ImGui buttons (…) would then work with that type.
Adding Create sounds reasonable. Still hesitant about merging back. @tonfilm@woei@antokhio What do you think
I wanted to bump this thread again, @everybody pls put a like if you want change or opinion why this change should not happen, @gregsn i guess we can just plan it for 7-alpha meanwhile
This would be my favorite solution. It addresses the core issue and aligns with what users naturally expect. If I understand correctly, it also solves all other cases where the value doesn’t change, but you still want to send the event, not just for Unit.
