Feature request: use environments instead of vars

[dankinsoid]

Now all chat configuration like showDateHeaders, messageUseMarkdown, avatarSize, etc, are simple variables and configured through methods from ChatView extension. It means, that it's possible to set them only locally, directly with a ChatView. I suggest to use EnvironmentValues instead that allows to setup all configs globally for the whole app and override them locally if needed. Example:

extension EnvironmentValues {

   public struct Chat: Equatable {
     public var type: ChatType = .chat
     public var showDateHeaders: Bool = true
     public var avatarSize: CGFloat = 32
     public var messageUseMarkdown: Bool = false
     public var showMessageMenuOnLongPress: Bool = true
     public var tapAvatarClosure: TapAvatarClosure?
     public var mediaPickerSelectionParameters: MediaPickerParameters?
     public var orientationHandler: MediaPickerOrientationHandler = {_ in}
     public var chatTitle: String?
     public var showMessageTimeView = true
     public var messageFont = UIFontMetrics.default.scaledFont(for: UIFont.systemFont(ofSize: 15))
     public var availablelInput: AvailableInputType = .full
   }

   private enum ChatKey: EnvironmentKey {
     static let defaultValue = EnvironmentValues.Chat()
   }

   public var chat: Chat {
      get { self[ChatKey.self] }
      set { self[ChatKey.self] = newValue }
   }
}

extension View {

    public func chatView<T>(_ keyPath: WritableKeyPath<EnvironmentValues.Chat, T>, _ value: T) -> some View {
       environment(\.chat[keyPath: keyPath], value)
    }

    // convenience methods for each var if needed
}

[f3dm76]

Hey @dankinsoid, that way you won't be able to use different settings for different chats in the same app. If you need many chats which are all the same, please just create a custom view wrapping the chat with the setting you need and reuse it. Have a nice day

[dankinsoid]

@f3dm76 Hi, why? Environments can be overriden. With environments you can define a default style at the app root view and customize it if needed for any specific chat. It works out of box

[f3dm76]

Yeah, but if you spread config code for chat across your project, it'll be easy to forget/lose part of it, and then get unexpected results. Also, I will have to use more specific names for all the setup - just using .type is ok for ChatView modifier, but not ok if it'll become a global thing. In the current approach, you'll be sure to have all you code in one place exactly where it needs to be. What is the benefit of environment approach, compared to using a wrapper?

[dankinsoid]

Benefits:

• Ability to set up styles when we cannot modify the code of the view or create a wrapper. For instance, when we use a library that utilizes ChatView under the hood, or a view that wraps a ChatView.
• Unified styling API. With a wrapper, you have to duplicate all styling methods to make it configurable.
• Access to the current chat style from any view that depends on the chat view style, for example, InputViewContent and MessageContent. It can also be some custom overlay or something else.
• Type independence: Currently, we have to write all chat style modifiers together and cannot insert any other modifiers between them. This is fine until we want to put some of them in a function to reuse.
• Unification: SwiftUI has a type-erased API with implicit DI, and while this has its downsides, it is the default approach in SwiftUI.

Strictly speaking, all these reasons are more important for small, highly reusable views like buttons, texts, checkmarks, etc., and they are not as important for a ChatView. However, I like environments a lot; they are highly useful, convenient and perfect suits for any styling.

[f3dm76]

These are good arguments, however, there are two sides to most of them:

• This is for example the case with MediaPicker library which I use inside ChatView. It is also our library, so I can modify it to use environment, but I don't want everything media picker can do to stick out of the chat. Not all the available setup is useful for a picker inside a chat. I'm limiting the MediaPicker to serve as a chat picker, cutting some functionality chat won't need. And it is always easier to support API which allow less - I cannot guarantee that everything will work as expected.

• Why would you duplicate everything? Just reuse what you need for every chat only creating params you need to change.

  struct MyChatView: View {
  // only params you are changing
  var showDateHeaders: Bool = true
  
  var body: some View {
      ChatView() {
          // all the other setup here - once per project
      }
  }
  }

• InputViewContent and MessageContent have everything they need inside their closures. In these closures there are things which cannot be set up through environment (view builders etc.). Since I want a unified approach I'm choosing a closure.
• This is a benefit in my book. There is no sense in spreading chat config all over the project, so I'm forcing users to do it where it needs to be. And there is no point in setting up .buttonStyle or .font for a chat in between other modifiers - it will do nothing. Also, you still won't be able to put too much into a function since swiftUI forces me to pass the view builders as a generic on ChatView. Modifiers perform basically the same thing as these view builders - just initial chat setup, so they go together.
• For a specific type (which ChatView undoubtedly is) SwiftUI gives specific API, for example .renderingMode on Image. Setting up . tapAvatarClosure is not at all the same as setting padding and fonts. For a chatTheme I use the environment as is customary in SwiftUI.

The bottomline is - unfortunately I don't like environment approach. Why make global that which can be local? Narrowing the scope is the first thing I've been taught as a programmer. We have encapsulation principal for a reason, and I think making everything global, while convenient, is potentially dangerous and gets hard to track fast.

Summing up:

• I want to manually control what is sticking out of libraries API, so I can better ensure that it works.
• There is always a way to not duplicate code, environment is not the only approach.
• I want a unified approach - I can do everything through vars; I can only so simple things through environment, and still will have to do the rest through vars.
• All chat configuration should be done in one place (where the chat is used) - it is not a project wide component like texts and buttons
• It's a pretty complicated component, with a very specific API, so one might be surprised to find its setup somewhere in AppView file
• Better keep things as local as we can
• As you said yourself, environment is a good fit for styling. Styling on this project is done through environment, everything else is not.