Consider adding the ability to use a dictionary as a view context

[fwgreen]

This might be a welcomed alternative to finding a unique name for something that, in most situations, doesn't require naming. Plus it has the added benefit of being familiar to someone coming from one of the many frameworks that use this approach.

My current approach, sadly, uses AnyCodable as Leaf's encoder isn't public.

import Vapor
import AnyCodable

extension ViewRenderer {
    public func render(_ name: String, _ context: [String: Any]) async throws -> View {
        let data = context.reduce(into: [:]) { $0[$1.0] = AnyCodable($1.1) }
        return try await self.render(name, data)
    }
}

Maybe making Leaf's builtin encoder public might be a possible compromise.

[gwynne]

This is already possible, see https://github.com/vapor/leaf/blob/main/Tests/LeafTests/LeafTests.swift#L20 for an example. What are you running into that's preventing you from doing this?

[fwgreen]

That test seems to only cover [String: String] but not [String: Any]. What I need is to be able to use a dictionary with a string key and a value of any encodable type.

[0xTim]

What's wrong with creating an inline Codable type to represent the information? Do you not know the contents at compile time?

[fwgreen]

There's nothing wrong with that approach, and I'm glad to have the option. The problem is being forced to find a unique name for a view context which doesn't require a name. It's fine for small projects but becomes unwieldy for larger ones. I'm assuming that's why, at least in the Java world, most (if not all) frameworks offer some sort of HashMap backed model type for this purpose.

[0xTim]

AnyCodable definitely won't work here, just investigated with another project and it doesn't have a stable API at the moment so there's no way we could use it.

Additionally the use of Any, (or even Sendable because Leaf will likely require Sendable contexts in the near future) kind of goes against Swift's strong type safety. You can create a nested context:

func someRouteHandler(_ req: Request) async throws -> View {
  struct Context: Encodable {
    // Whatever you want here
  }
  let context = Context(...)
  return try await req.view.render("template", context)
}

That provides the flexibility without needing to extract and name everything (though I'm still a big proponent for that, especially in large projects as it makes it clear what's needed and makes it easier to test). I think any addition would need to reach quite a high bar given the current APIs available

[fwgreen]

@0xTim My apologies if my choice of words made it seem as if I wanted to include AnyCodable in Vapor. To be clear, I do not. It was my reliance on AnyCodable that drove me to make the feature request in the first place. Is it possible (for my own personal extension) to use Leaf's own encoding facilities? I looked but did not see any public API for an encoder.

[0xTim]

@fwgreen which parts to you want made public?

[0xTim]

(Just to clarify, we could probably make LeafEncoder itself public, though I'm reluctant to do it until we've completed the Sendable work but a lot of the extensions are way to coupled with Leaf's internals to be made public)

[fwgreen]

Making LeafEncoder public seems more than enough for what I hope to achieve. However, I'm more than willing to relinquish the dream if the price is a major overhaul. Thanks for taking the time to look into this.