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

Major fixes #59

Closed
wants to merge 14 commits into from
Closed

Major fixes #59

wants to merge 14 commits into from

Conversation

CachedImage.js Outdated
},

getDefaultProps() {
return {
renderImage: props => (<Image ref={CACHED_IMAGE_REF} {...props}/>),
renderImage: props => (<ImageBackground ref={CACHED_IMAGE_REF} {...props}/>),
Copy link
Owner

Choose a reason for hiding this comment

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

Why do you prefer ImageBackground over Image?

Copy link
Author

Choose a reason for hiding this comment

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

React recommends to use ImageBackground.

Copy link
Contributor

Choose a reason for hiding this comment

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

To confirm, using ImageBackground would require implementors of react-native-cached-image to update to 0.46? If so and @kfiroo is happy with this, this should probably be denoted as a peerDependency in the package.json.

Copy link
Author

Choose a reason for hiding this comment

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

Added alternative in "progressive enhancement" style for ImageBackground facebook/react-native@9637dd4

CachedImage.js Outdated
@@ -211,6 +219,16 @@ const CachedImage = React.createClass({
style={activityIndicatorStyle}/>
)
});
},

renderError() {
Copy link
Owner

Choose a reason for hiding this comment

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

We would probably want to give the users a way to render their own errors.
What do you think? A prop for renderError?

Copy link
Author

Choose a reason for hiding this comment

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

Good.

@kfiroo
Copy link
Owner

kfiroo commented Jul 18, 2017

@iegik WOW! Thanks for all the good things! I really appreciate your help! :)

I absolutely loved the use MemoryCache to manage url expiry! Great Job!

Any chance you could update the README to reflect your changes?
I think its an amazing improvement to the previous version, thanks again.

As a side note, this would have been a lot better as separate PRs with a descriptive title so we could reason about it better :)

@iegik
Copy link
Author

iegik commented Jul 18, 2017

MemoryCache - is not the best solution. It uses AsyncStorage for saving relative data (we could save some info about image).

  • We can cache images as Blobs in AsyncStorage, to reduce calls to fs.
  • Save expiration date somewhere else?
  • Save expiration date in memory on fly while application runs, but in that case wi will not clean our cache after app relaunch.

@iegik
Copy link
Author

iegik commented Jul 18, 2017

It`s hard for me split job. I just learning to do that.

Copy link
Contributor

@mattvot mattvot left a comment

Choose a reason for hiding this comment

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

Thanks for the work @iegik. Just a few things I've seen to be looked at but this is much appreciated!

// 'Response': {
// Raw: toFile
// }
// });
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this commented code required, and could it be removed before merging?

// Error: err
// }
// });
})
Copy link
Contributor

Choose a reason for hiding this comment

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

Same with this catch that will swallow all errors, unless that is the intention?

Copy link
Owner

Choose a reason for hiding this comment

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

I agree, looks like the comment was supposed to include the catch clause?

package.json Outdated
"crypto-js": "3.1.9-1",
"lodash": "4.17.4",
"react-native-clcasher": "git+ssh://git@bitbucket.org/clcorpdevelopment/react-native-casher.git#aa8ead1",
Copy link
Contributor

Choose a reason for hiding this comment

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

This should be a version number to the npm package.

@kfiroo I'm weary of this dependency addition.

  1. It's a private repo
  2. The NPM package has no readme https://www.npmjs.com/package/react-native-clcasher

It would be good if the required caching functions are included in this library.

Copy link
Author

Choose a reason for hiding this comment

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

I added following documentation. Will be available in next release.
Currently, we do not expected, that package will available as private. We will fix this later. It`s free.

Also, I think, we should provide flexible caching provider.

MemoryCache

Extended AsyncStorage with expiration check

AsyncStorage can only save data forever. If you want save data for some period of time and clean outdated data -
use following API:

  • set(key: string, value?: mixed, expires?: seconds) - Stores data by key and expiration time in seconds
  • get(key: string) - Returns stored data by key
  • remove(key: string) - Clear data by key
  • multiGet(keys: array) - Get data by keys
  • multiSet(values: object, expires?: seconds) - Store multiple data with expiration time in seconds
  • multiRemove(keys: array) - Clears storage by specified keys
  • flush() - Clear storage
  • isExpired(key: string) - Checks of data expiration
  • getAllKeys() - Returns all stored keys
  • getAllValues() - Returns all stored serialized values

Installation

npm install --save react-native-clcasher

Usage

const MemoryCache = require('react-native-clcasher/MemoryCache').default;

MemoryCache.set(url, headers, maxAge)

@@ -1,7 +1,8 @@
'use strict';

const _ = require('lodash');

// const debug = require('console-network');
Copy link
Contributor

Choose a reason for hiding this comment

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

To remove?

Copy link
Author

Choose a reason for hiding this comment

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

I use my own console-network tool for debugging Image HTTP request (print in console).
There is delemma:

RNFetchBlob.fetch()
    .then(/* Here we can get HTTP response*/)
    .catch(/* Here we can get fetch error */)
    .then(/* finally */)
// ...
.catch(/* Here we can get file move error */)

How we can provide normal interface for catching fs / fetch errors?

@iegik
Copy link
Author

iegik commented Jul 18, 2017

Tested on RN v0.39.2

@kfiroo
Copy link
Owner

kfiroo commented Jul 19, 2017

@mattvot Thanks for the review! :)
@iegik Don't worry about splitting the PR, it was just a friendly advice for the future :)

In response to #59 (comment) :

  • Why don't you like AsyncStorage for keeping images metadata (such as ts, ttl, size, hash? I don't see any other valid option. Keeping Image data only in memory would mean that you can't tell if it is expired, or how long it's in the cache
  • Saving images as blobs in AsyncStorage doesn't sound like a solid plan to me, I'm afraid I'm not sure about the limits of such thing. (Is there a limit on a single entry? Is there a size limit to the storage? etc.) + it seems like the fs calls are fast enough (right?)
  • It feels like all metadata about a url should be kept in the AsyncStorage

Also, if I got that right, react-native-clcasher is your repo? If so, you could publish it and change the version number to the npm one. (I'm happy to help if you need anything)

So, to conclude, I think keeping URL Metadata in some sort of persistent storage (e.g. AsyncStorage or MemoryCache) is a great addition to this lib, but I'd like to think about the API some more and maybe add some tests as the logic seems to be getting more complex.

@iegik
Copy link
Author

iegik commented Jul 19, 2017

@kfiroo I think is too much requests to fs (AsyncStorage, saving to TMP, moving), but it`s seems to be ok.
Here, I save headers to AsyncStorage. https://github.com/kfiroo/react-native-cached-image/pull/59/files#diff-684d138fd2e5cef7a2e12df1792166e1R258 TTL (or expiration date) stores automatically by react-native-clcashier. Other info can be included later.

I think we can merge now, or I missed something?

renderImage: props => {
return (<Image ref={CACHED_IMAGE_REF} {...props}/>)
},
renderImageBackground: props => {
Copy link
Owner

Choose a reason for hiding this comment

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

@iegik Why do we need another prop for renderImageBackground?
I'd rather have the original renderImage test for ImageBackground and fallback to Image for older versions

Copy link
Author

Choose a reason for hiding this comment

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

renderImageBackground aka ImageBackground is needed only when we have children, otherwise we should use old Image.
children for images we use for placeholders only.

@torbjorn-kvist
Copy link

Is there any status on this PR to be merged?

@kfiroo
Copy link
Owner

kfiroo commented Sep 14, 2017

@Dvidan I think all issues were resolved with v1.4.0
Let's try to create new issues with a more specific topic so we can discuss them properly :)

@kfiroo kfiroo closed this Sep 14, 2017
@aofeng2009
Copy link

aofeng2009 commented Sep 27, 2017

@iegik When I cover install my app, Images gone. see issues #83

@iegik
Copy link
Author

iegik commented Sep 28, 2017

@aofeng2009 Please, read carefuly https://github.com/kfiroo/react-native-cached-image/releases/tag/v1.4.0

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.

5 participants