Git Product home page Git Product logo

typescript_emitter's People

Contributors

dependabot[bot] avatar stratus51 avatar

typescript_emitter's Issues

Need a method to map input values

The Emitter manages both an input stream and an output stream. As such, it as common to try to map the input as it is to map the output.

Currently the output can be mapped using the map method. However, mapping the input requires quite some boilerplate.

Should this new method be named "map_input", or "wrap", ... ?

Routing emitter

A new type of emitter would be useful: a load balancer.
It would have the same prototype as the first emitter except that subscribed callback would tell whether the have successfully processed the package.

The newly required acks could be processed synchronously or asynchronously (payload processing could require I/Os).
There should probably be 2 separate implementations because the asynchronous implementation will probably consume quite a lot of memory compared to the synchronous one.
The synchronous one will also easier to implement.

The acks should be integrated in the map, filter and relay methods.

emitter/listener object split would allow clearer/safer code

If we could split the Emitter into some kind of EmitterSender and EventListener, each keeping their associated methods (map, filter, map_input, ...), it would allow the code to restrict the actions possible on the forwarded emitter.

For exemple, only a Sender would be forwarded to a producer and a Listener would be sent to consumers. This would insure the consumers don't accidently inject packets to other consumers for exemple. Also the code would be clearer about whether the Emitter handle is used as a source or as a sink.

API naming convention

Is pub/sub naming relevant?

As the enhancement issues are suggesting, the lib might be migrating to a object stream model. Therefore would a push/each naming convention (iterators) be more relevant?

Emitter builder

In practice, an I/O client will often serve as a builder for multiple data streams (request streams over different topics on MQTT or AMQP which will have to be processed independently).

Formalizing the notion of an emitter builder could be useful?

ImmediateEmitter thrown errors affect other listeners

If a listener throws an error, it prevents any further propagation of the signal to the next listeners.

Should we force the Emitter test to verify that signals aren't lost upon error emission?
What should we do with the potential caught errors? (Global error callback? Per listener error callback?).

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.