Does @Shared introduce the same sort of problems that singletons have?

[tzzoug]

I'd first like to thank you for all the content, you guys have taught me a lot over the years. I just have a Q about the @shared property wrapper's pattern.

If a parent feature passes down a part of it's state as a shared property to a child feature, it means that the child feature could update the value of that property at any time without the parent feature receiving an action or knowing about it.

Wouldn't that introduce inconsistent parent feature behaviour as the state of the parent could be modified from an external source without a direct action on the parent for it to be aware of such changes.

Example: Tests written for feature A might pass in a test suite consistently, but if changes are made by a feature B at runtime to a shared state that feature A uses, it might cause feature A to have unexpected behaviour.

My understanding was that the singleton pattern (static let shared = MySingleton()) introduces such problems because effects would take place without the feature being aware of it, and the @shared property wrapper is giving me the same impressions.

Could you elaborate as to why my reasoning might be off?

Thanks

[mbrandonw]

Hi @tzzoug,

We cover this in detail in our series of episodes building the state sharing tools.

At the end of the day, sharing state is absolutely necessary in pretty much every non-trivial app. The moment you want to read from or write to a file on disk, you now have shared state in your app and any part of the app can write to the file without you knowing. Same goes for user defaults, or user sessions, or really any external system you can read from and write to.

Shared state is just a fact of life, and there truly is no way to build an app without it. So then the only question is, what tools can be built to make shared state more understandable and testable? And that is why we built our @Shared property wrapper. It allows you to share state amongst features in an app while still maintaining testability, and even exhaustive testing (i.e. you are forced to prove how shared state changes in order to get a passing test).

Example: Tests written for feature A might pass in a test suite consistently, but if changes are made by a feature B at runtime to a shared state that feature A uses, it might cause feature A to have unexpected behaviour.

That situation is also possible even without shared state, and even without using TCA. If FeatureA contains the logic and behavior of FeatureB, then you can write a test that passes for FeatureB but fails when run as a test on all of FeatureA. And that's because FeatureA can decide to apply additional mutations to the state in FeatureB.

So that is not specific to @Shared or TCA. In reality you just need to write tests not only for individual leaf features, but also for how features integrate together.

My understanding was that the singleton pattern (static let shared = MySingleton()) introduces such problems because effects would take place without the feature being aware of it, and the @shared property wrapper is giving me the same impressions.

That is one problem that singletons introduce, but the other (more serious) problem is that singletons make the code completely untestable. So even if you wanted to write a test to prove that a bunch of your features behave the right way when they access the shared state, you wouldn't be able to.

Hope that helps.

[tzzoug]

I guess the way things were done prior to the @shared wrapper was that things were more explicit (tho more verbose), meaning that the child would typically send a delegate action and so the parent had full visibility of when it's properties would change. (Not that I want to write that kind of code as it was very verbose indeed).

And I am also very much on board with the fact that singletons are not testable. In that regard, the @shared wrapper has huge advantages for testability.

I guess at the end of the day, it's a matter of pros/cons to be weighed project by project.

Thanks for the reply Brandon