Consider removing Codable requirement for State

[CoreyKaylor]

Is your feature request related to a problem? Please describe.
I'm using SwiftDux with a shared model in Kotlin-Native. This poses challenges with the Codable requirement.

Describe the solution you'd like
Ideally the requirement of having State be Codable should be removed as it is by nature an extension of the core.

Describe alternatives you've considered
Wrapping the primary state type with a wrapper that is Codable. This adds a lot of indirection and unnecessary complexity IMO.

[CoreyKaylor]

Let me know if you're interesting in taking a PR for CoreyKaylor@3c87ecc or some variation of it.

[StevenLambion]

Hi @CoreyKaylor, I'm sorry for such a late response to this issue.

I completely agree that the codable constraint creates unnecessary friction. I'd be glad to take a look at the PR.

[StevenLambion]

Because StateType is more of a convenience and the Store class doesn't rely on it, I'm tempted to go in a direction that implements conditional protocol conformance in spots where codable and equatable might be required. In that case, the developer would be responsible to add the correct protocol on their state objects.

The reasoning behind this is the fact that the core classes don't require StateType, but other classes do when a conditional conformance would suffice. I can then mark StateType as deprecated.

Does this sound reasonable?

[CoreyKaylor]

@StevenLambion I can relate to long delays in replying to issues, no worries there. I like your proposal over mine.

[StevenLambion]

I've pushed the change out to the latest release. I haven't marked StateType as deprecated yet, but the library is no longer constrained to it.

[CoreyKaylor]

Looks great and works for the scenario I described. Thanks for the changes.