Jump to content
This forum will be closing down. Please move to the respective dedicated project forums.

What would you recomend to replace Signals?


user471
 Share

Recommended Posts

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 => ...)

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

 

 

 

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...