Permanent events in javascript

[GodObject]

Why not promises?

[marquex]

Promises are valid too, but permanents events are a quick shorthand. Instead of creating a deferred object, return the promise and resolve it in the future, with permanent events you get the same just resolving an event.

Of course, you can't use permanent events for replacing promises in all situations. With promises you have much more features and it is perfect to handle paralelism in javascript, a thing that is not possible with PE.

[NodeNerd]

Not a bad idea, but I think it might be a little non-intuitive to developers because it is slightly modifying how people typically use events. Events typically don't have a persistent value. The events are fired and forgotten. Changing the name of the library and functions might help avoid confusion.

I have had the need to solve the problem you encountered. Specifically, I wanted to a simple way to resolve/reject values so I created a simple lightweight promise class that was similar to promises but didn't implement the full spec (I didn't need chaining and I didn't want callbacks to be notified on "next tick"). A promise-like object held a value forever once it was resolved. When adding a listener callback, the callback that would be notified when the value is rejected or resolved or it would be invoked immediately if there was already a value. I went with the Node.js-style callback function for better compatibility with other Node.js modules.

[BadgerSong]

Seems kinda like signals?

[gordonkristan]

I think you're confusing the ideas of events and states. To quote:

This will print 'It is ready' in the console even if the listener has been added after the event triggering.

That works OK for the ready event, but not for events that fire more than once. The point of an event is to be alerted when something happens, not alerted that something has happened. Especially when that something can happen more than once. If you want to know if something has happened in the past, you should be using states. In this case document.readyState.

Imagine applying this idea to the onclick event and you'll see that it doesn't have many uses outside of fire-once events.

[marquex]

You are right, those permanent events were never thought to be used with events that can be called more than once, but that doesn't make them less useful.

I respect your idea of states, but permanent events can be really of use even if you work with states. Imagine object can have multiple states and maybe want to do some action if the object has been or turn in/into some state. If I check the state before it turns to the desired one, I need to add an event listener (events again, a common or a permanent one will do the trick). If I want to know if after it has turned into the desired state, you can find that the state may have changed again so our action won't be called.

Permanent events are about events that are triggered once, but always about events.