Replies: 1 comment
-
We would expect that any "internal" actions don't ever need to be scoped to. Can you explain a bit more why you are scoping to those actions, ideally sharing some compiling code that demonstrates what you are currently doing? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi folks 👋
My team is a big fan of TCA, and we build our software product using Swift Package Manager. When it comes to integrate our product into an app which is also using TCA, we need the feature to have
publicaccess so that we can compose it inside an AppFeature (reducer) in our app.In summary, we have something like this in the app:
For this to work, in the Package,
MainFeaturemust be public. e.g.For this to work, it means that
OtherFeature.Actionat least must also be public - and this is a daisy chain effect. Everything which is referenced, inMainFeature.Actionmust be public, which leaks all sorts of implementation details outside of the package.Swift 5.9 introduced the
packageaccess level modifier, which is great for a modular package codebase, and there are Swift evolution discussions around access level modifiers for enums. In the meantime though, does anyone have any techniques to get around this problem?What we've done so far, is to create a
public struct Actionin theMainFeatureto wrap aninternal enum _Action. This allows us to make public some actions, but keep internal the child actions. We then had to jump through some hoops to try to createAnyCasePathvalues, and needed to rely on deprecated APIs to scope the store. In general, I've found that it's pretty tricky to create aCaseKeyPathby hand, because@CasePathablecannot be used in this scenario.Beta Was this translation helpful? Give feedback.
All reactions