-
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ditch EventEmitter #75
Comments
What's the real reason you're asking this question? Because Could you please clarify? Thanks! |
I think I was trying to say that the event emitter pattern has some downsides to cleanup/deallocation. Like there is no way to remove a listener without explicity keeping reference to the callback function. ES6 generators&iterators provide a modern elegant alternative for event streams, that is also dependency free. Apologies for the term meta package, I didn't mean to say that it doesn't contain code. I guess my real question is why is EventEmitter depended on internally when the public API encourages |
If you're looking for sugar, use the const { on } = require('events')
for await (const event of on(db, 'put')) {
console.log(event) // [key, value]
} As for doing that dependency-free, we might some day. The amount of reasons for having events (in any form) is slowly decreasing. For example, instead of
One part for historical reasons and backwards compat, and one part because events are synchronous, which is a better fit. |
Yes your example provides de-initialization which is good. I am not familiar with level-db internals so i cannot say if all listeners attached must manually be cleared in order to let the garbage collector liberate resources. But I'm somewhat traumatized from hunting As for sugar no. I'd love to see smaller dependency footprints. I hope my concerns were received well, I enjoy working with abstract-level & browser-level but I wish the impact on the dependency tree was less. |
+1 replace 'events' This is a node specific module, and it breaks building this for the browser. If you want to keep the event emitter interface, I would move to something in user-land, like nanoevents. |
I want to add some nuance to that. Webpack, Browserify, Vite and more are perfectly capable of bundling Level modules, although some make it painful by requiring configuration. It's unfortunate that the larger JavaScript ecosystem moved away from node shims because it removed the ability to reuse them. So now one module is using e.g. The |
In addition to @vweevers 's point, the definition of worst depends on what we're looking at. It's been a while since I've last done a thorough testing session but insofar as I am aware, callback-based patterns (through It would be nice to not have to shim |
True about factoring things for deduplication in a broader context. As a working solution, I have installed the npm module |
Hello, I imported package
browser-level
and received the following error
I feel having dependencies for node primitives in a meta-package such as abstract-level is overkill.
Would it be possible to move away from EventEmitters in favour for async generators or at worst a single function subscription pattern?
The text was updated successfully, but these errors were encountered: