What would you recomend to replace Signals?

[user471]

Phaser 3 uses eventemitter and callbacks and I want something similar to Signals from Phaser 2. What should I use?

[rich]

You should use Event Emitter and callbacks.

[user471]

5 hours ago, rich said:

You should use Event Emitter and callbacks.

When JS is moving from callback hell to abstractions like Promise and Rx why would I what to use callbacks?

It's much easier to work with Signals. For example when I need to wait all events to complete I can do something like this
 

waitAll(x.onComplete, y.onComplete, z.onComplete).addOnce(x => ...)

 

[PixelPicoSean]

The DOM API uses Event Emitter like approach, and you can still use Promise and Rx on top of that. And Rx does have event emitter support, you only need to create streams for the events you are going to use.

[user471]

12 minutes ago, PixelPicoSean said:

The DOM API uses Event Emitter like approach, and you can still use Promise and Rx on top of that.

I know. The problem is promises doesn't fit because they doesn't support subscription and Rx is to heavy, so I am looking for something like Rx but lightweight.

[PixelPicoSean]

There're a lot of FRP libraries, I've used kefir.js and flyd, both of them are really great (and also support EventEmitter like interface) and much better than Rx IMHO.

[rich]

One day I really ought to write an article about what's good for a web app is almost never good for a game loop.

[snowbillr]

That would actually be a really helpful article. I come from a web dev background and would love to see what the do's and don'ts are compared to that and game dev best practices.

[rich]

I just found it amusing that the original post was asking what to use instead of Signals in v3 (the answer is, of course, Events), and then gave an example of something a Signal couldn't ever do anyway.

The biggest issue is that web devs lead almost exclusively asynchronous development lives. The overwhelming majority of your code and practices are honed around this, and there are so many libs out there to help with it. Which makes perfect sense, it's how the web itself works after all. Look at Promises, created specifically as a proxy to an as-yet-unknown value. A very common occurrence in web apps.

In a game, this is almost never the case though. Very rarely do you ever have to wait for the value, it is nearly always calculated instantly (or should be) or available elsewhere in memory. So introducing an artificial async jump into this value fetch is a really backward step. It's the same with data streams too. Unless you are genuinely fetching remote data all you've actually managed to do is add overhead to a situation that didn't need it.

The absolute shortest possible path for your data is the best. Retrieved in the fewest jumps possible, with minimal or no branching, invocations or creation of un-necessary objects (which includes anonymous functions, those wonderful little bundles of gc bait). This goes against everything that is standard for a web app. But you're not building a web app.

[user471]

4 hours ago, rich said:

an example of something a Signal couldn't ever do anyway.

What do you mean? You can do something like this

  function waitAllOnce(signals: Signal[]) {
    const signal = new Signal()
    var count = 0

    signals.forEach(x => x.addOnce(() => {
      count += 1
      if (count == signals.length) {
        signal.dispatch()
      }
    }))
    return signal
  }

4 hours ago, rich said:

Very rarely do you ever have to wait for the value

Every time you need to use EventEmitter you have an asynchronous process and you need to wait for the value. So if a game doesn't use too much events it wouldn't be a problem. But if it's something like a puzzle game it's very similar to web app, just a complex UI. If it uses tweens for  animations and you want to do something after this animations you can use Event Emitter, but it's just easier to use some abstraction over it.

 

 

 

[rich]

I meant that Signal.waitAll isn't a native feature of Signals. If you're going to hand-roll it like in your example above then anything is possible and it becomes irrelevant if you use Signals or Events, either would work.