Implementing SharedEvents about red HOT 7 CLOSED

second option sgtm

from red.

I'm thinking of exposing it as SharedEvent (which would use Call mode) and SharedSignalEvent, since Call mode makes more sense as a default to me - it matches the behaviour of the previous Events API more closely, and more often than not you won't need more than one connection.
Writing out SharedCallEvent every time seems unnecessarily wordy to me.

from red.

Is there any reason that call events cannot yield? Also apologies, but I don't remember the issues I had, I think they just failed in tests and I didn't want to bother implementing them.

from red.

Is there any reason that call events cannot yield? Also apologies, but I don't remember the issues I had, I think they just failed in tests and I didn't want to bother implementing them.

I haven't thoroughly read the backend yet but I assumed since they aren't spawned, a yield would also delay all the other callbacks from the same batch of events.

from red.

Is there any reason that call events cannot yield? Also apologies, but I don't remember the issues I had, I think they just failed in tests and I didn't want to bother implementing them.

I haven't thoroughly read the backend yet but I assumed since they aren't spawned, a yield would also delay all the other callbacks from the same batch of events.

Nevermind, re-read it and this is not true. I'll amend the issue.

from red.

Here's a snag:

Since the function can return two different types depending on what arguments are passed, the intellisense doesn't know what to display. It also doesn't add placeholder parameter names when autocompleting.
This isn't a huge deal but does worsen the DX a little bit.

Here's the type in question:

type ConstructorType =
	(<T...>(Options: SharedCallEventOptions, Validate: ValidateFunction<T...>) -> SharedCallEvent<T...>)
	& (<T...>(Options: string | SharedSignalEventOptions, Validate: ValidateFunction<T...>) -> SharedSignalEvent<T...>)

I've got three solutions in mind:

• Leave it as it is, it's a pretty minor issue to change the API over.
• Create two different functions, one for creating a Signal event and one for creating a Call event. Since they have different APIs I think two different functions for creating them can make sense.
• Unify the Call and Signal event types, so they both share the same API. This does lose the distinction between them outside of their declaration though, so when reading code you'll have to go back to the event creation to check if it's a Call or a Signal event.

I'm leaning towards the 2nd option, but it is very minor so just leaving it as is would probably be fine.

from red.

Adding FireWithFilter from the old Event API too as FireFilteredClients

from red.