What if we render image only when `renderImage` property is available? about react-native-cached-image

[kfiroo]

@iegik Hey, thanks for the detailed response! :)

I agree that it will provide us with amazing customization capabilities for ImageCacheProvider that are now not so straight forward.

Taking this to a more practical level, I think we could have our stand alone ImageCacheManager (what we call today ImageCacheProvider) that should be used by ImageCacheProvider component that should reside at the top of your app and define the Cache behaviour.

The ImageCacheProvider would provide the customized ImageCacheManager to all CachedImages that are in its subtree using the context.

One could still use the stand alone API and provide his own customizations, same as today.

What do you think?

[kfiroo]

Created a v1.4 branch, I'll push some more changes today, then I'll create a PR for it and we could continue the discussion over there :)

Sounds good?

[kfiroo]

@iegik Hey
You could actually use the ImageCacheProvider to do various actions.

I feel like the CachedImage component is the simplest way to cache images, it's a simple drop-in replacement for the Image component and works great out of the box.
For some more advanced use cases you can use the ImageCacheProvider and cache some urls when the app starts or clean the cache.

Why do you think having the CachedImageProvider as a component is better?

[iegik]

Here I want to compare ImageCacheProvider with NavigationProvider or StyleProvider. I assume, that is possible create such Provider, who watches on its children`s and do some staff on their`s properties:

<ImageCacheProvider>
    <Image .../>
    <image .../>
</ImageCacheProvider>

So, I think CachedImageProvider - can be also a component.
I understand, that You want to separate logic for rendering image and caching that image.

[kfiroo]

The problems I see with this is that the Images would have to be immediate children of the ImageCacheProvider and I, personally, wouldn't like it in my code.
Moreover, this pattern is mostly used as a way to provide a certain behaviour to an entire sub-tree by passing some functionality through the context and again I'm not sure this is the case here.

What are the pros of this kind of a solution? What can we gain that is currently not possible?

[iegik]

The problems I see with this is that the Images would have to be immediate children

Ok, You are right here.

pattern is mostly used as a way to provide a certain behaviour to an entire sub-tree

Benefit of this pattern - You can always (enable) cache or pass (disable) caching by changing property of "caching provider". It is abstract layer for image loading mechanism.

it's a simple drop-in replacement for the Image component and works great out of the box

I found, that removing loading template out of the box and rendering method - will make CachedImage component much lighter. But why CachedImage? we just need make transparent only one component to provide basic functionality out-of-the-box!
Let's do it in "Provider"!?

Here is some variants of usage (I apologize for #61 (comment)):

1. Using provider for each Image

<ImageCacheProvider source={image}>
    <Image source={image} />
</ImageCacheProvider>

2. Make own CachedImage

let CachedImage = (props) => {
    let {sources} = props;
    return <CachedImageProvider sources={[...images]} renderImage={props => (
        <ResponsiveImage {...props} />
    )} />
}

<CachedImage sources={...}/>

3. Preloader for some cases

<ImageCacheProvider sources={[...images]}/>
...
<Image/>
<Image/>
...

[iegik]

MB, git flow init -d and create v1.4 branch?

[kfiroo]

@iegik what does that do?

[iegik]

https://github.com/nvie/gitflow