Consider adding the ability to use a dictionary as a view context about leaf HOT 9 OPEN

(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)

from leaf.

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?

from leaf.

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.

from leaf.

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

from leaf.

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.

from leaf.

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

from leaf.

@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.

from leaf.

@fwgreen which parts to you want made public?

from leaf.

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.

from leaf.