JoshMarler
commented
4 years ago @nick-thompson, in the middle of implementing two-way event dispatch at the moment as a test, so I can open up a PR if you like the sound of this idea?
EventBridge could end up becoming a class with your typical pub/sub pattern. Something like the below (probably more elegant though :-)):
class EventBridge {
constructor() {
this.subscribers = [];
__BlueprintNative__.dispatchEventFromNative = (event, data) => {
if (!subscribers[event]) return;
this.subscribers.forEach((subscriber) => {
subscriber.callback(event, data);
});
}
}
publish(event, data) {
__BlueprintNative__.dispatchEventToNative(event, data);
}
subscribe(event, callback) {
if (!subscribers[event]) {
subscribers[event] = []
}
let index = subscribers[event].push(callback) - 1;
subscribers[event] = { index: index, callback: callback };
return index;
}
unsubscribe(event, subscriberIndex) {
if (!subscribers[event]) return;
subscribers[event].splice(index, 1);
}
}Obviously there are pros and cons to be weighed up around "Stringly Typed" event based systems.
In regards to making EventBridge a bit more elegant, I'm assuming you could use EventEmitter still, I'm not super familiar with it. What would be the best pattern to allow client code to call both EventBridge.emit("beginParameterChangeGesture") and EventBridge.on("beginParameterChangeGesture", callback) without self notifying etc.
Something along the lines of this?
class EventBridge extends EventEmitter {
constructor() {
super();
__BlueprintNative__.dispatchEventFromNative = (eventType, ...args) => {
this.emittingFromNative = true;
this.emit(eventType, ...args);
this.emittingFromNative = false;
}
}
// Override EventEmitter.emit()
emit(eventType, ...args) {
if (this.emittingFromNative) {
super.emit(eventType, ...args)
}
else {
__BlueprintNative__.dispatchEventToNative(event, ...args);
}
}
}Where dispatchEventToNative might look a bit like the below. Where eventHandler is a public assignable std::function object on ReactApplicationRoot.
void registerNativeEventHandler()
{
engine->registerNativeMethod("__BlueprintNative__", "dispatchEventToNative", [](void* stash, const juce::var::NativeFunctionArgs& args) {
auto self = reinterpret_cast<ReactApplicationRoot*>(stash);
jassert (self != nullptr);
jassert (args.numArguments >= 1);
const juce::String eventType = args.arguments[0].toString();
std::vector<juce::var> eventArgs;
if (args.numArguments > 1)
{
for (size_t i = 1; i < args.numArguments; ++i)
{
eventArgs.push_back(args.arguments[i].clone());
}
}
jassert(self->eventHandler);
if (self->eventHandler)
{
self->eventHandler(eventType, juce::var::NativeFunctionArgs(
juce::var(),
eventArgs.data(),
eventArgs.size()));
}
return juce::var::undefined();
}, (void *) this);
}
nick-thompson
Currently
ReactApplicationRootandEcmascriptEnginesupport pushing events from native/C++ code into JS/React via thedispatchEventmechanism.dispatchEventis a function registered/created against the global__BlueprintNative__object by EventBridge.js.It seems that a lot of apps and client code would benefit from a generic "event based" framework or pattern to communicate between C++ and JS.
For example, it would be nice to both send an
event(consisting of an ID and payload/args) from C++ to Javascript and from Javascript to C++.I might wish subscribe to a "parameterChanged" event in JS and also trigger/signal that same event back to C++.
Is this something that blueprint could/should offer via
EcmascriptEngine/ReactApplicationRoot?I could imagine a complimentary function to
ReactApplicationRoot::dispatchEventalong the lines ofReactApplicationRoot::Listener::handleEvent.i.e.
(
ReactApplicationRoot::Listeneris purely there to illustrate a point, could be a lambda callback or whatever)This might require some change or "fleshing out" of
EventBridgeto support apublishandsubscribelike interface.The big initial question feels like "Should Blueprint provide this or should examples be given with data-flow patterns/implementations left to the users of Blueprint?"
@nick-thompson I'd love to hear your ideas around this area. I'm going to implement some sort of event based communication in my app over the coming days so will let you know if I come up with any interesting stuff.
For me it would be super useful just to have an inverse dispatchEvent function that I can call from JS and listen to in C++. We have plans to build a generic data model/controller system off some sort of simple pub/sub mechanism.
I don't think that dictates design patterns to users too strongly as there are plenty of other approach people could use but it does give a tool that various patterns can be built off of.
This could also work really nicely with a
ValueTreewhere events are id'd to match a value tree property identifier. A component owningReactApplicationRootcould then listen to events from JavaScript to update its value tree. Said component could also listen to the value tree itself and dispatch the same event to JavaScript, allowing straight forward 2 way data binding with an application's data model.The
ValueTreeapproach would allow super straight forward undo/redo behaviour in apps managed withValueTreeas undo/redo would automagically update the JSUI's controls. A tonne of if/else comparators on property identifiers could be avoided if the events received from JS could just map straight toValueTree::setValue(event.id, value). C++ code could also listen to theValueTree::valueTreePropertyChangedcallback and push the value of the changed property straight into JS usingdispatchEvent. It feels like this could provide a nice generic system for many apps. Might need some careful thought to try and apply as much strong typing as possibly as this will be throwing around a lot of string id's andNativeFunctionArgs.The
ValueTreeevent based approach should be interoperable with AudioProcessorValueTreeState to provide a solution for both plugins and larger standalone apps. We could probably provide some sort of helper class for this and offer it as a basic "data flow" tool. People could choose whether or not to use it in their applications. Not everyone is going to want this but I think it could provide some real value.Dave Rowland did a great talk on managing large scale apps with juce::ValueTree. Might make a nice reference.