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

Allow changing the cache root directory #38

Merged
merged 4 commits into from
Jul 19, 2017
Merged

Conversation

sladkoff
Copy link
Contributor

@sladkoff sladkoff commented May 9, 2017

This PR addresses what I already mentioned in #36:

Background

Files in the default cache directory may be purged by the Android OS automatically to free up space. While this is fine in most cases, you may want to make sure that the cached images are permanent (when implementing an offline-mode for example).

API changes

This PR introduces a cacheLocation prop in CachedImage and a cacheLocation option in ImageCacheProvider. All utility functions like clearCache now take an optional parameter as well.

Possible values:

  • ImageCacheProvider.LOCATION.CACHE (='cache') -> fs.dirs.CacheDir
  • ImageCacheProvider.LOCATION.BUNDLE (='bundle') -> fs.dirs.MainBundleDir

Everything falls back to 'cache' so there should be no breaking changes.

Feedback appreciated

I tested the CachedImage component and some of the caching functions in ImageCacheProvider. I did not get to test all of the utility functions like collectFilesInfo, clearCache, etc.
I verified that the images are stored in the respective directories.
I updated the README.
I only tested on Android

It'd be cool if your could look over the changes and test if you have the time.

Let me know what you think. I can fix stuff if needed.

- Adds cacheLocation (cache|bundle) options to CachedImage and ImageCacheProvider
- Uses respective directories for caching
@kfiroo
Copy link
Owner

kfiroo commented May 10, 2017

@sladkoff Thanks! This look awesome! :)
I'd want to take a closer look just to make sure nothing breaks and that iOS works as expected but other then that it looks great!

@mattvot
Copy link
Contributor

mattvot commented May 23, 2017

@sladkoff Hey, looks good. Do you have time to add Document directory support too? Thanks

@sladkoff
Copy link
Contributor Author

@mattvot It would be very easy to add support for the document directory, yes.
I'd like to hear back from @kfiroo before implementing it.

PS. We're currently using my forked version in our app and everything's working out great so far.

CachedImage.js Outdated
@@ -116,7 +118,9 @@ const CachedImage = React.createClass({
processSource(source) {
const url = _.get(source, ['uri'], null);
if (ImageCacheProvider.isCacheable(url)) {
const options = _.pick(this.props, ['useQueryParamsInCacheKey', 'cacheGroup']);
let options = _.pick(this.props, ['useQueryParamsInCacheKey', 'cacheGroup']);
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why the change to let?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No reason, will revert to const. I think I missed that during cleanup.

@kfiroo
Copy link
Owner

kfiroo commented Jun 5, 2017

@sladkoff Hey! Thanks for this!
So sorry for the delay, haven't been around my computer for a while..

I'd really like to merge this ASAP, this is a great PR :)

CachedImage.js Outdated
@@ -46,15 +46,17 @@ const CachedImage = React.createClass({
React.PropTypes.bool,
React.PropTypes.array
]).isRequired,
resolveHeaders: React.PropTypes.func
resolveHeaders: React.PropTypes.func,
cacheLocation: React.PropTypes.oneOf(Object.values(ImageCacheProvider.LOCATION)).isRequired
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd consider making this a string value instead of an enum to allow more flexibility.
We could expose the LOCATION enum with some convenience values, but still allow the user to input what ever he wants
What do you think?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I concur with this. A future change I would like to add is to support falling back to multiple cache locations.

One of our applications would be bundling a set of content to the app on for release. We'd like to directly reference the bundled cached files if avaliable (rather than seeding by duplicating or pulling a fresh cache down).

By accepting cacheLocation as string, this may be one step closer to our requirement.

@kfiroo
Copy link
Owner

kfiroo commented Jun 5, 2017

@sladkoff I left some comments in the code, basically I'd rather have the cache prop as a string for flexibility
Other then that it looks good to me :)

@sladkoff
Copy link
Contributor Author

sladkoff commented Jun 9, 2017

@kfiroo Thanks for the feedback. I'm currently on vacation, will fix this up next week B)

The `cacheLocation` option can now be specified as a string. `ImageCacheProvider.LOCATION` contains default / convenience values. Updated readme.
CachedImage.js Outdated
@@ -47,7 +47,7 @@ const CachedImage = React.createClass({
React.PropTypes.array
]).isRequired,
resolveHeaders: React.PropTypes.func,
cacheLocation: React.PropTypes.oneOf(Object.values(ImageCacheProvider.LOCATION)).isRequired
cacheLocation: React.PropTypes.string
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made cacheLocation path fully customizable via string option.

.then(() => fs.exists(dirPath).then(exists => {
// Check if dir has indeed been created because
// there's no exception on incorrect user-defined paths (?)...
if (!exists) throw new Error('Invalid cacheLocation');
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had to add this workaround in order to be able to properly throw an exception when a user-defined cacheLocation path could not be created. Let me know if there's a better way.

CACHE: 'cache',
BUNDLE: 'bundle'
CACHE: fs.dirs.CacheDir + '/imagesCacheDir',
BUNDLE: fs.dirs.MainBundleDir + '/imagesCacheDir'
};
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The LOCATION enum still contains some defaults / convenience values.

@sladkoff
Copy link
Contributor Author

@kfiroo The latest version supports custom cacheLocation paths. Let me know what you think!

@kfiroo
Copy link
Owner

kfiroo commented Jul 9, 2017

@sladkoff Sorry for the delay! I was away for a while.
I see @mattvot created a PR (#52) that includes the functionality you suggested here.
I wanted to get you opinion on this, if you think this PR covers both issues I can merge it alone, otherwise I'll merge both.
What do you think?

@sladkoff
Copy link
Contributor Author

sladkoff commented Jul 9, 2017

@kfiroo The other PR includes this one, so it should be fine if you only merge #52.

@kfiroo
Copy link
Owner

kfiroo commented Jul 10, 2017

@sladkoff Cool, thanks.
So I'm closing this one

@kfiroo kfiroo closed this Jul 10, 2017
@sladkoff
Copy link
Contributor Author

@kfiroo Just a proposal - since #52 seems to require some more time, would you consider merging this separately?
I'd like to stop using our fork (which I need to keep up to date separately) as dependency.

@kfiroo
Copy link
Owner

kfiroo commented Jul 19, 2017

@sladkoff Hey, I agree, I think we should move forward with this PR.
I just have some comments here #38 (comment) and I'd like to go over the changes and see if we can do this a bit better.
I'll try to do it today!

@mattvot
Copy link
Contributor

mattvot commented Jul 19, 2017

Hey, I'll try and put some time into resolving the issues with #52 today and tomorrow. Hopefully you won't be waiting much longer @sladkoff 😀

@sladkoff
Copy link
Contributor Author

@kfiroo Cool. Just let me know what you have in mind and I'll get on it.
I went for a straight-forward approach, I think. There's always room for improvements.

@mattvot Didn't mean to rush you :)

@kfiroo kfiroo reopened this Jul 19, 2017
@kfiroo kfiroo merged commit 6aac317 into kfiroo:master Jul 19, 2017
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.

3 participants