Open fwgreen opened 10 months ago
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?
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.
What's wrong with creating an inline Codable
type to represent the information? Do you not know the contents at compile time?
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.
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
@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.
@fwgreen which parts to you want made public?
(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)
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.
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.Maybe making Leaf's builtin encoder public might be a possible compromise.