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

Redundant conformance of 'Color' #1420

Closed
6 tasks done
blackyhn opened this issue Nov 29, 2021 · 8 comments · Fixed by #1761 or #1768
Closed
6 tasks done

Redundant conformance of 'Color' #1420

blackyhn opened this issue Nov 29, 2021 · 8 comments · Fixed by #1761 or #1768

Comments

@blackyhn
Copy link

Hello,
I'm getting error when triyng to extend the SwiftUI.Color because of the Color struc extension.

"redundant conformance of 'Color'"

Thanks in advance!

Check these before submitting:

  • The issue doesn't involve an Unsupported Feature
  • This issue isn't related to another open issue

This issue is a:

  • Non-Crashing Bug (Visual or otherwise)
  • [] Crashing Bug
  • Feature Request
  • [] Regression (Something that once worked, but doesn't work anymore)

What Platform are you on?

  • [] MacOS
  • iOS

What Language are you in?

  • Swift
  • [] Objective-C

Expected Behavior

I expect to extend SfiwftUI.Color wihtout issues.

Actual Behavior

I'm getting the "redundant conformance of 'Color'" error because of the extension of the Color struct.

@erwinmaza
Copy link

It's not just Color that's an issue, there are several structs defined in lottie-ios that share a name with SwiftUI structs. This is a problem for any project using this library and extending SwiftUI primitives.

For now I've worked around this issue by adding this to my project:

extension View {
	// resolve naming conflicts with dependency libraries
	typealias Color = SwiftUI.Color
	typealias Group = SwiftUI.Group
	typealias Animation = SwiftUI.Animation
	typealias Rectangle = SwiftUI.Rectangle
}

and I keep having to add to this list as I build out my app's infrastructure.

Despite this, I've also had to explicitly use the SwiftUI namespace in some files, like so

extension SwiftUI.Color {
	static let myColor = SwiftUI.Color([my custom color])
}

But this should not be necessary. A longstanding best practice for libraries is to "namespace" their custom objects by prepending them with a custom identifier, usually the library or author's initials. So, for example, lottie-ios Color should be renamed LTColor or ABNBColor or similar.

As SwiftUI gains adoption in more complex production apps, these name conflicts will become more of a problem, and will increasingly be a barrier to adopting this library and Lottie in general. Please consider renaming all your public primitives.

@calda
Copy link
Member

calda commented Aug 10, 2022

Renaming these public types would be a breaking API change, so we would need to do it in a Lottie 4.0.0 release. I started a discussion about this here: #1713

@calda
Copy link
Member

calda commented Aug 10, 2022

Do Lottie.Group and Lottie.Rectangle actually cause issues in SwiftUI projects? Those types are internal.

@liudhzhyym
Copy link

Any new progress on this issue?
I have face same problem when I use lottie-ios in SwiftUI project

@calda
Copy link
Member

calda commented Oct 7, 2022

@erwinmaza We're renaming Color and Animation, since those types are public. I see you mentioned Rectangle and Group as well, but those types are internal. Are you encountering conflicts from those types? If so, could you share a piece of sample code?

If this is causing a problem we'd like to also fix it in Lottie 4.0, which we are releasing in a few weeks.

@erwinmaza
Copy link

I'm incorporating the library as source code in my project (I prefer full source control and stability, plus I've customized it a bit), so internal is visible to the rest of my app.

As an aside, I moved from the typealias solution to renaming the types in the source files myself.

Great to hear that 4.0 is coming out soon. I've had "Update Lottie to 3.4.0" for the performance improvements in my backlog for awhile. Now I'll just wait for 4.0 so I don't have to rename things again.

Thanks for addressing this issue.

@calda
Copy link
Member

calda commented Oct 10, 2022

I see, thanks for the info -- I think I'm going to leave them as-is for now. Since those types are internal we can rename them in the future without breaking source compatibility, we don't need to make that change specifically in Lottie 4.0.

@calda calda reopened this Oct 11, 2022
@calda
Copy link
Member

calda commented Oct 11, 2022

We made the first step towards resolving this issue in Lottie 3.5.0. We will fix the issue completely in Lottie 4.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants