vault-development / react-native-svg-uri

Render SVG images in React Native from an URL or static file
849 stars 334 forks source link

Add ability to customize fill color #105

Closed pgom closed 6 years ago

pgom commented 6 years ago

Following the proposed solution detailed on https://github.com/vault-development/react-native-svg-uri/issues/86, this PR allows to defined a custom fill value for svg elements without any defined fill attribute

hitmanmcc commented 6 years ago

It would be cool to have this merged, we need this as well.

matc4 commented 6 years ago

I have a doubt whit this change, can cause that some elements that should not have fill attr, get colored, what do you think?

pgom commented 6 years ago

@matc4 for that cases, I believe that not setting the fill prop would serve, right?

matc4 commented 6 years ago

@pgom its possible that you have an SVG with 10 elements, 5 with the fill attr, and 5 without.
Actually, only the 5 elements with fill attr get color changed. Whit this PR 10 elements will be colored whit fill attr.

This will be the desirable behaviour in all cases?, It is possible that some of that elements must remain without the fill prop?

I'm not sure if this is a possible scenario

pgom commented 6 years ago

I see what you mean @matc4. We are using this mainly to display icons and they are intented to have a single color. But without this change, I'm unable to change the color of the svg. Any suggestions? Maybe adding a new flag to control this behavior? Something like icon={true|false}?

egid commented 6 years ago

@matc4 do you have a suggested alternate solution? Because right now all SVGs seem to render black, ignoring fill (which is listed in the readme as a supported prop).

This is a bug with a working solution; please consider releasing a version with support for fill.

From the readme:

fill Color   Overrides all fill attributes of the svg file

The documented behavior sounds exactly like the thing you are concerned might happen with this fix.

matc4 commented 6 years ago

Hello @egid , the documentation says that "overrides" the fill attr of the svg file, but this PR "adds" fill attr to svg elements that previously they did not have, is not the same.

I understand the problem that you have in your use case, but my concern, is if this PR will "break" for other uses cases.

I don't have a solution yet. i'm trying to think possible solutions

egid commented 6 years ago

Got it. I misunderstood what was happening under the hood and have gone back and re-read.

imo, if an SVG contains no fill attributes (which seems to be our problem with black SVGs, and likely what is hitting @pgom and @hitmanmcc), we should apply the specified fill to all paths. If the SVG already contains fills, then perhaps we only override.

The icon={true} syntax also seems reasonable, or perhaps something less specific like fillAll={true}.

pgom commented 6 years ago

I like fillAll better, actually 👍. @matc4 wdyt? I can change this PR to include that logic.

matc4 commented 6 years ago

@pgom Yes, i think that 'fillAll' is more representative.

pgom commented 6 years ago

@matc4 please take a look at the latest changes.

egid commented 6 years ago

Any chance we can get this merged sooner than later?

egid commented 6 years ago

Please :D

ilya-vaikutis commented 6 years ago

Please also add corresponding type definitions.

pgom commented 6 years ago

What do you mean @ilya-vaikutis?

ilya-vaikutis commented 6 years ago

@pgom, new property should be also described in TypeScript type definition file (index.d.ts).

pgom commented 6 years ago

Added @ilya-vaikutis

pgom commented 6 years ago

@matc4 did you take the change to review this? 😄

egid commented 6 years ago

Just following up - it'd be great if this could merge soonish.

egid commented 6 years ago

Looks like this project is pretty dead. Does anybody have an alternative? Should we just fork this and maintain it locally?

matc4 commented 6 years ago

Hello @egid , i will merge all the pending pull request, and i will need help to test the final state of the library, so we can make a new release

egid commented 6 years ago

If you publish a prerelease version, I know that we will be happy to install it and test it out.

egid commented 6 years ago

Any status changes?

egid commented 6 years ago

Excellent! Thank you.

egid commented 6 years ago

Should we be pinning directly to github master to test this out, or will y'all be releasing a prerelease version?

egid commented 6 years ago

@matc4 any plans for a release any time soon?