Thoughts on Hashable Actions

[JacksonUtsch]

Currently my practice for cancellable identifiers is using the hashValue of my actions. Hashable conformance is not a necessity for Actions but I find it can be convenient and auto synthesized conformance takes place frequently. Does this solution lack some functionality?

[tgrapperon]

Hello!

From my experience, it's very difficult to have a root Action that can conform automatically to Hashable. As soon as some associated value isn't hashable, you need to implement hashable conformance for the whole type hosting the action. And you don't need to go far to encounter non-hashable types like CGSize or Animation. Of course, you can conform types you don't own to protocols you don't own, but this is generally considered a bad practice, and you see immediately how this can be tricky in some semi-opaque cases like Animation.

Aside from this, you will have as many identifiers as cases in your action. This usually works fine, especially for "naked" cases without associated values, as you probably have more cases than you need. You can imagine adding new cases to only play the role of identifiers, but I clearly don't recommend it. One advantage over the "standard" way @EffectID are used (that is, internal to the reducer) is the possibility to cancel effects across reducers (as you can reach the action, hence, the effect identifier). @EffetID can also be defined outside the reducers, but not as top-level properties (Swift doesn't allow top-level usage of property wrappers for now).

This library also provides namespacing that can greatly improve reusability, and you don't get this automatically without @EffectID.

So if you manage to have Hashable actions and it's working fine for you, then you're not losing much, but I would say it's a very unorthodox practice. It seems very rigid, and you can possibly end up in a corner at some point where it won't work. Fortunately, effects identifiers can be any hashable value, so you'll always have an exit route.

Having Hashable actions is a very strong requirement. If you're using them only to avoid declaring something, I would advise reconsidering the usage of Strings, Hashable empty types, or @EffectID. The day you'll need a leaf action that has a non-Hashable (or even non-Equatable) associated value, you will need to make the action Hashable, or break all your reducers.

So yes it can work, especially with raw cases and if the domain helps, and you immediately enjoy their benefits, but you may have to pay the price later, implementing things that will need to bear some logic (and thus, brainpower), whereas identifier declaration is always straightforward.

I hope this answer your question.

[JacksonUtsch]

Great! I can see some potentially dangerous cases now with using the Action’s Hashable. Thanks 🙏