Re-add support for local images
Looks like I may have missed it during development of v0.1.0.
Reproduction Instructions:
- Set Props.bricks = [LocalImages (require('../asset/etc')]
- Images won't load
Validate:
- When passed in a local image, it should appear in the columns
Does this mean the example is void? I had a look through your code and it appears that you are indeed using uri in the source prop of the Image component:
<Image
key={image.uri}
source={{ uri: image.uri }}
resizeMethod='auto'
style={{ width: image.width, height: image.height, marginTop: gutter }} />
Just trying to get it running myself with remote images!
@dazziola Ahh my apologies, I meant to put "local" images -- just corrected it. But yes, remote images will work. Let me know if you are having issues with getting it to work.
Thanks for catching that.
Hmmm, I'm having a weird non-descript problem. I'm using the data block of images as per your example with two columns, however they're not rendering in the simulator or on a physical device.
@dazziola What version of RN and React are you running?
"react-native": "0.43.3", "react": "16.0.0-alpha.6",
@dazziola Hmm I just ran a fresh install of the example, no issues currently. Are your images HTTPS or HTTP? If you are on IOS, by default IOS causes non-secure images to fail (https://github.com/facebook/react-native/issues/8520).
Also does your debug log show up any information? react-native-masonry will inform you if an image has failed to load as a warning, so you should see that if it's an issue with loading the network image.
I've cloned the example and you're right, it works perfectly. Hmmm, I'll mess around with my one and see if I can figure out what it is. Thanks for the prompt responses! If it's anything other than my own silly oversight, I'll be sure to post it here for future people!
@dazziola Absolutely! Please let me know what the issue was, maybe we can clear up or improve the readme 👍 .
Still currently trying to resolve this issue without the need to require a local image prop or something like that. Ideally I want the users to be able to set { uri: localFilePath }, which currently resolves to a number -- I believe is the id within the asset manager. If anyone knows, please lmk!
@brh55 Well why are you assuming source={{ uri: image.uri }}, I wouldn't do that. Just let the user pass whatever, you're just a front for the Image API
@fxfactorial Would work, but then local images wouldn't be able to leverage other properties such as onPress, renderHeader, renderFooter.
@brh55 How so?
@fxfactorial I'm assuming you are referring to users passing in react elements like
bricks = [<Image source={require('../asset1.jpg')} />, <Image source={uri: 'http://image.com/url1.jpg' } />]?
Hmm, I wasn't but that seems like a fine solution as well.
Ahh what other way are you referring to?
bricks = [{img: require('../asset1.jpg')}, {img: {uri: 'https:....'}}]
I mean, just a front for the source prop of Image.
OHH yeah that should work, I'm not sure why I was having issues before.
@brh55 actually now I'm thinking, should let end user provide their own Image component, or whatever view they give. Why assume masonry desired is image?
For example, what if I wanted to use this: https://github.com/oblador/react-native-image-progress
@fxfactorial Interesting yeah you could overload the Image component with any desired image component. Well without images, it's rather straightforward to achieve the sme effect: flex: row, justifyContent: space-between.
So RNM was initially to solve this issue using remote images, since it needs to fetch the image and pass on the proper size to the image component. But RNM has grown to fit others needs along the way haha.
How do you mean to overload?
Ah let me rephrase that -- I think it would be neat if you could use a custom image component, and it's probably possible.
By having a property that could allow users to pass a component for RNM to use in the rendering process instead of the default image component -- assuming the third-party component had source as a property.
I'm sure there is another way of doing this that I perhaps am skipping over.
right, definitely some room for generalization
Indeed, theoretically it should work.
Per suggestions, there is still some underlying bundling that is occurring not allowing it to work as imagined technically. Going to leave this open, and welcomed for anyone to try and come up with a viable solution.