Skip to content
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

Updated version that works with browserify, and fixes unnecessary purging #2

Merged
merged 9 commits into from
Apr 26, 2015

Conversation

ropez
Copy link

@ropez ropez commented Apr 26, 2015

The purpose of this PR is to see if there is anyone paying attention to this project.

We're been using (a copy of) Monsur Hossain's jacache in our software for several years. Now we need to fix a couple of issues, and would like to use it as a proper npm package, using browserify.

I found this fork that has already done some of the work of porting it to npm. I've re-purposed this for browserify, by removing the "dynamic" require calls, and added new tests for the localStorage backend.

I've also fixed an issue with the purge function being called many times when adding many items to a full cache.

Now, I would like to start pushing this to npm, and maybe set up a travis-ci job for running the tests. The question is, would it be Ok if I just went ahead and published this as "cachai" on npm, or do you want to hold on to the maintainer status, as the one that came up with the name?

ropez added 9 commits April 25, 2015 11:38
Using a simple mockup to be able to test local storage in mocha. The
test cases are adapted (simplified) from the old test cases that were
removed in a previous commit.
Makes the default constructor work with browserify.

Other storage backends need to be required and instantiated:

```
// before
new Cache(maxSize, false, 'local_storage')

// after
CacheStorage = require('cachai/lib/storage/local_storage')
new Cache(maxSize, false, new CacheStorage())
```
Instead of setting auxiliary timers to drive the tests, having to use
'done' callback to avoid silent failures. This is simpler to read, and
should give better error messages when tests fail.
If the current size of the cache is larger than the new max size, we
call purge. It's not really necessary to check if the new size was
larger than the old size before checking the current size.

The advantage is that the test is now identical to setItem(), so it
can be generalized.
Purging in resize() is now deferred, like in setItem()
When inserting many items in one synchronous "thread", and the cache max
size is exceeded, make sure we only set the timeout to purge the cache
once!
rstuven added a commit that referenced this pull request Apr 26, 2015
Updated version that works with browserify, and fixes unnecessary purging
@rstuven rstuven merged commit f3573d9 into rstuven:master Apr 26, 2015
@rstuven
Copy link
Owner

rstuven commented Apr 27, 2015

Thanks, Robin. :)
I've merged your PR, published to npm, set up a travis-ci job and also added code coverage tooling (see package.json scripts section; coveralls.io is somewhat unstable though) and gave to the documentation some love.

@ropez
Copy link
Author

ropez commented Apr 27, 2015

Fantastic, thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants