user471

What would you recomend to replace Signals?

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

 

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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.

 

 

 

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.