How is it possible to see all listeners on channel at some moment ? (I mean phoenix-js and client-side js code)
Something, like this:
channel.eventListeners = ['event1', 'event2'] ...
I found all I need in channel.bindings
Related
How can I do with a validation rule so that, for example, from the New state I only get to click Assigned. The rest of the states should give an error message or blocked (I don't know if it can be blocked)
Read up about PRIORVALUE() function, for example https://developer.salesforce.com/forums/?id=906F00000008pFfIAI
Something like this should do the trick
ISCHANGED(Status)
&& ISPICKVAL(PRIORVALUE(Status), 'New')
&& !ISPICKVAL(Status, 'Assigned')
This is also an interesting take: https://trailhead.salesforce.com/trailblazer-community/feed/0D54S00000A7SPhSAN
I have some basic code like this:
this.events$
.pipe(
observeOn(asyncScheduler),
...
).subscribe(anotherObservable$);
This works fine in my app, but I am having a funny issue with a unit test. I put a couple of debug consoles like this:
this.events$
.pipe()
.subscribe(console.log.bind(null, 'sanity check inside without async'));
this.events$
.pipe(observeOn(asyncScheduler))
.subscribe(console.log.bind(null, 'sanity check inside with async'));
If I do from(events).subscribe(events$); in my test, the "without async" log fires.
If I do scheduled(events, asyncScheduler).subscribe(events$);, nothing fires.
I can't seem to fake the input to get my pipe on the async scheduler to fire. My test just needs that pipe to fire to see that something was called.
Realized right after posting:
scheduled(events, asyncScheduler).subscribe(events$);
await lastValueFrom(events$)
My question is simple, yet still hard to do... I want to be able to only display one (1) message at a time using toastr.js
I have tried the following options already:
"maxOpened": 1,
"limit":1
None of those work and result in this:
How can I achieve that when there is a new message, the older one closes and displays the new message?
Try this:
toastr.options.preventDuplicates = true;
I'm using SerilogMetrics's BeginTimedOperation() in a Web API, and it would be really great to be able to use the HttpRequestNumber or HttpRequestId properties (from the respective Serilog.Extra.Web enrichers) as the identifier, making it super easy to correlate timing-related log entries with others across a request.
Something like:
using (logger.BeginTimedOperation("doing some work", HttpRequestNumberEnricher.CurrentRequestNumber))
{ ... }
Short of poking around in HttpContext.Current for the magically- (i.e. non-public) named properties, is this achievable? Thanks!
If you begin a timed operation during a web request, the operation's events will already be tagged with the HttpRequestId.
You'll see it when logging to a structured log server like Seq, but if you're writing it out to a text file or trace then the property won't be included in the output message by default. To show it in there use something like:
.WriteTo.File(...,
outputTemplate: "{Timestamp} [{Level}] ({HttpRequestId}) {Message} ...")
The logging methods use a default template you can draw on for inspiration, and there's some info spread around the wiki though there's no definitive reference.
I am reading the marionette.js docs and I don't understand the difference between vent, reqres and commands.
The only thing I clearly understood is that commands should not return anything.
Can anyone explain it a little bit?
Let's start from the top: Backbone.wreqr is a Backbone plugin that ships with Marionette. It provides three messaging patterns for loosely-coupled applications.
This answer includes example code from the Backbone.wreqr documentation - credit to the original authors.
Events
EventAggregator objects work like Backbone.Events - they enable namespaced event handing. vent is simply a common variable name for an EventAggregator object:
var vent = new Backbone.Wreqr.EventAggregator();
vent.on("foo", function(){
console.log("foo event");
});
vent.trigger("foo");
Commands
Commands are very similar to Events. The difference is semantic - an event informs other parts of the application that something has happened. A command instructs another part of the application to do something.
var commands = new Backbone.Wreqr.Commands();
commands.setHandler("foo", function(){
console.log("the foo command was executed");
});
commands.execute("foo");
Request/Response
RequestResponse objects, which are often referenced by a variable called reqres, provide a loosely-coupled way for application components to request access to objects:
var reqres = new Backbone.Wreqr.RequestResponse();
reqres.setHandler("foo", function(){
return "foo requested. this is the response";
});
var result = reqres.request("foo");
console.log(result);
Radio and Channels
As a convenience, Wreqr provides an object called radio which mixes in the three messaging patterns. Commands, events and requests can be grouped into logical channels to prevent interference - you may need distinct save commands for user and document channels, for example.
In Marionette
Marionette.Application creates instances of Commands, RequestResponse and EventAggregator inside a channel ("global" by default) using the conventional variable names. If you need custom behaviour you can override the vent, commands and reqres variables.
_initChannel: function() {
this.channelName = _.result(this, 'channelName') || 'global';
this.channel = _.result(this, 'channel') || Backbone.Wreqr.radio.channel(this.channelName);
this.vent = _.result(this, 'vent') || this.channel.vent;
this.commands = _.result(this, 'commands') || this.channel.commands;
this.reqres = _.result(this, 'reqres') || this.channel.reqres;
},
Link to source
I suggest you read the Wreqr docs for more detail. I also recommend reading through the Marionette annotated source - it is concise and very well documented and, in fact, includes the Wreqr source.
N.B. The next major release of Marionnette, v3.x, replaces Wreqr with Radio. Radio provides the same functionality as Wreqr with a cleaner API. It is possible to use Radio in Marionette 2.x applications, which I recommend if you are starting a new app.
ReqRes Messenger
The reqres messenger can both send a message, (which consists of the named event as well as optional parameters), to a target and relay a response back to the source (which will be in the form of the returned parameter of the target function)
Command Messenger
The command and vent messengers are functionally very similar, but fulfill different semantic responsibilities.
The command messenger is used to invoke the execution of a target function. Generally, one function is bound to a command handler. Like the OP stated, in a command the direction of communication is one-way, meaning that whatever the command target returns will not be sent back to the source incoming the command.
VENT Messenger
Finally, vent messengers are event aggregators. You can attach (subscribe) many listeners to the vent and all of them will receive an event that is triggered (published) by the vent. Each listener will invoke a function associated with that listener When an event in a vent is triggered it may also send each listener a set of parameters.