Presentation Logic

[danielmoro]

Hi all,
I'm wondering where is the place for presentation logic in TCA?
For example, I have to display date and some numbers from my model on the screen. Easiest way is to instantiate some formatters in the view, and then to use them with values from the State objects. But I guess that this is wrong on many levels.
Next, I can have some sort of Presenter that will be responsible for formatting values, and formatters will live inside it. In that case presenter should produce State or be a State object. If it should provide state how it should be instantiated and who will be its owner?
Next, maybe I can provide formatters as environment injection, but in that case it is not clear should I pass somehow formatters to the view and maybe initialize TextField with formatter? I don't see any way to do that. I can use formatter in environment when value is being set to the state in the reducer, but I don't know how to use them when I'm getting value from State object.
Does anybody have strategy for cases like these?

[andriyslyusar]

As of now I am keeping Date, Number and Name Formatters as part of State, this allow me easily use them then constructing ViewState from State. But I am feeling that it is the wrong way to do it and instead they should be part of Environment. I would love to hear more opinions on this topic.

[siejkowski]

I keep formatting logic in reducer. If I want to use an external formatter, I have it in the environment. My rule of thumb is that the ViewStore provides the view with the information that are already processed and ready to be shown without additional work. So formatting, sorting, filtering etc. is done in reducer.

[lukeredpath]

I don't think presentational code belongs in your store (and therefore your state/environment) at all. It's inherently part of your view layer. There's a number of ways of wrapping up this presentation logic:

• Use the Presenter pattern and wrap your ViewStore in a presenter that can format values from the state that are appropriate for the view.
• Have helper properties on your view that format the state values how you want - this is probably the simplest option and would be fine if you don't need to use this formatting elsewhere.

Adding this presentational logic to your store doesn't give you any real benefits and may actually complicate testing - you would be much better IMO testing this presentational logic by creating instances of your views, passing in a store with pre-configured state, and snapshot testing them. This allows you to test your view renders correctly in all the different states you want to test and potentially across all kinds of presentational configurations - different locales, color schemes, light/dark mode, screen sizes etc.

A compromise between the two approaches above, where you want something re-usable but don't want to necessarily have an entire wrapper around your view store, is to extend ViewStore constrained to the state you are trying to present, e.g.:

extension ViewStore where State == SomeState {
  var someFormattedValue: Any { }
}

You could then re-use this formatting logic on any screen that uses a view store for this type of state and you could unit test these small formatting helpers if needed. This extends on the idea of the ViewStore being equivalent to a view model.

Re: the above comment, I don't really see sorting and filtering as the same thing as formatting - the latter is generally a purely presentational concern, where as how your data is sorted or filtered is actual application logic and is something you'd want to keep inside your store. I'd also keep any user-controllable formatting inside the store as that feels more like application logic than purely presentational logic.

[danielmoro]

So, do you think that someFormattedValue property should create DateFormatter every time property value is requested? Alternatively, some static var in extension can be used to hold formatter, but in that case there is implicit dependency, and also formatter cannot be changed during life time of application.
On the other hand, how to inject formatter from environmet in extension to be used in calculated property?

This goes beyond formaters... themes, styling etc are also some dependencies that should be provided from outside world and it seems that they need to somehow end up in view store, not in reducer.

[siejkowski]

Sure, I understand that approach. I just make the distinction between the application logic and presentational logic in a slightly different place.

For me the transformation of the data that is being shown — any transformation, really, that's why I've listed both sorting and formatting — is part of application logic. Formatting is usually some form of function from data type (like Date, number, string) into different data type (usually string). I liked to have it encapsulated within the view model and in TCA it's encapsulated within the reducer. Of course it doesn't mean all the logic is in reducer — it could be provided by the environment.

The presentational logic for me is all about layouting, rendering, size calculation, conditionals deciding what to show and what to hide, animations etc. I usually keep it in the view layer.

Not saying that's the best approach or anything, it just happens to fit my current mental model best 😄

[lukeredpath]

You definitely don't want to be creating DateFormatter (or any formatter really) every time because they are expensive to create. Create it once for a specific format and reuse it.

[andriyslyusar]

I am thinking about ViewStore as of ViewModel from MVVM pattern, so ViewState and ViewAction are what UI present (name, age, ...) and actions triggered (didPressLogout).

So as an example we have Profile screen with next state

struct ProfileState {
    var user: User
}

in our view layer we are only interested in presenting the full name, so we do not need a User object in ViewState, so we convert it to String by using the formatter.

extension ProfileState {
    var profileViewState: ProfileViewController.ViewState {
        fullName: personNameFormatter.string(from: .init(givenName: user.firstName, familyName: user.lastName)),
    }

In this example personNameFormatter is part of ProfileState.

[AlexisQapa]

I try to canonise what is stored in store. If you only use a value in a single format I would format it before storing thought I usually defer the formatting to rendering. For this I have a formatter cache which lazily load a formatter when requested and cache it. I forward the cache using @EnvironmentObject.