Compare commits

..

No commits in common. "master" and "v1.0.4" have entirely different histories.

5 changed files with 11 additions and 19 deletions

View File

@ -1,7 +0,0 @@
root = true
[**]
indent_style = tab
tab_width = 4
charset = utf-8
end_of_line = lf

2
LICENSE Executable file → Normal file
View File

@ -1,4 +1,4 @@
Copyright (c) 2014-2023, Alex A. Naanou Copyright (c) 2014, Alex A. Naanou
All rights reserved. All rights reserved.
Redistribution and use in source and binary forms, with or without Redistribution and use in source and binary forms, with or without

17
README.md Executable file → Normal file
View File

@ -11,7 +11,7 @@ will provide the following functionality:
* Call new handlers of the specified event with each of the prior event * Call new handlers of the specified event with each of the prior event
data sets in order of event occurrence. data sets in order of event occurrence.
* Add a `.clearGuaranteedQueue(<event>)` method to the emitter to facilitate * Add a `.clearGuaranteedQueue(<evetn>)` method to the emitter to facilitate
event cache cleaning. event cache cleaning.
This is useful for modules like [glob](https://github.com/isaacs/node-glob) This is useful for modules like [glob](https://github.com/isaacs/node-glob)
@ -58,8 +58,7 @@ emitter.emit('event', 'some data')
``` ```
A real-life use-case using the excellent [glob](https://github.com/isaacs/node-glob) A real-life use-case:
utility:
```javascript ```javascript
var glob = require('glob') var glob = require('glob')
var guaranteeEvents = require('guarantee-events') var guaranteeEvents = require('guarantee-events')
@ -82,14 +81,14 @@ results.on('match', function(path){ console.log('found: '+path) })
Cache cleaning and use for long running emitters Cache cleaning and use for long running emitters
------------------------------------------------ ------------------------------------------------
One of the dangers in using this in long running event emitters is _cache This is not recommended for use in long running event emitters as each
buildup_ -- the data for each event emitted will get stored and this event emitted data will get stored and might get quite large, i.e. a
might get quite large, this, if not managed, is a potential memory leak. potential source for a leak.
To deal with this issue a `.clearGuaranteedQueue(<event>)` method is To deal with this issue a `.clearGuaranteedQueue(<event>)` method is
added to the emitter, this will clear the cache for a specific event. added to the emitter, this will clear the cache for a specific event and
This and has a shorthand form `.clearGuaranteedQueue('*')` that will a shorthand form `.clearGuaranteedQueue('*')` that will clear the cache
clear the cache for all wrapped events. for all wrapped events.
So for the above example: So for the above example:
```javascript ```javascript

0
index.js Executable file → Normal file
View File

View File

@ -1,6 +1,6 @@
{ {
"name": "guarantee-events", "name": "guarantee-events",
"version": "1.0.6", "version": "1.0.4",
"description": "Guarantee that every event handler gets every event...", "description": "Guarantee that every event handler gets every event...",
"main": "index.js", "main": "index.js",
"scripts": { "scripts": {
@ -18,7 +18,7 @@
"event" "event"
], ],
"author": "Alex A. Naanou <alex.nanou@gmail.com> (https://github.com/flynx)", "author": "Alex A. Naanou <alex.nanou@gmail.com> (https://github.com/flynx)",
"license": "BSD-3-Clause", "license": "New BSD",
"bugs": { "bugs": {
"url": "https://github.com/flynx/guaranteeEvents/issues" "url": "https://github.com/flynx/guaranteeEvents/issues"
}, },