How to import in Partial?

[stephenafamo]

Partials allow us to have args.

How can I add an import to the manifest so I can use an argument type from a different package in my partial?

[bobf]

Hi, @stephenafamo , depending on your use case you might be able to inline the import:

@args(foo: @import("bar").baz)

But I think this might be problematic. I would recommend instead to put the logic in your view function to unpack the value into basic types and insert into your view data.

If you want to share more details about your use case I can try to provide some suggestions, or maybe you will help me find some limitations in Zmpl that I can solve by adding new features.

[stephenafamo]

I've been able to sort of figure out the import in a fork, but I'm facing other problems since I can only pass primitive types to data.put()

What I truly desire from zmpl is "Type-Safe Templates".

The issue with zmpl's data.init, data.put is that it is possible to try run into issue where what the template expects is different from what is passed to it.

With partials requiring Args, I can almost get my desired type safety, but since I can't pass complex types down to the partials, I am forced to encode it to a string (maybe json) and then decode in the template

The ideal scenario for me is that for each template, I can set the args (similar to partials) and those args will be the only data available to the template.

NOTE: I am using only zmpl, not jetzig

[bobf]

@stephenafamo Yeah I think that's a reasonable expectation. The reason for things working the way they do is because I want all template data to be JSON compatible, that way every endpoint can render HTML via Zmpl or JSON, so every Jetzig app gets a JSON API for free. But if that causes more problems than benefits then it's not the right design choice.

Let me have a think about it, if I can find a nice way to allow adding arbitrary types to Zmpl without breaking existing functionality then I'll be happy to add it, and if you wanted to submit a PR then that would also be welcome.

I think probably we can add renderT to Zmpl, which accepts a type and a value of that type, so you could invoke it like:

template.renderT(MyType, my_value);

I'm sure I can adapt the same approach to partials as well, since they are also just Zig functions under the hood. Maybe a new partial syntax like:

@partialT foo/bar(MyType, my_value)

I'm on a train right now but I'll try to look at it this weekend.

[stephenafamo]

Let me have a think about it, if I can find a nice way to allow adding arbitrary types to Zmpl without breaking existing functionality then I'll be happy to add it, and if you wanted to submit a PR then that would also be welcome.

One way would be to check that it implements a json_encode function and call that for json encoding. Or would this not be possible?

[bobf]

Yeah, that one is already on the TODO list - anything that implements toJson will have that function called when the data is encoded, I need that for the datetime stuff I added recently, but e.g. Jetzig's database layer leverages automatic struct transformation into Zmpl datatypes, so maybe we need toZmpl as well (or instead ? If a value can be converted to native Zmpl types then it's already JSON-encodable). We can definitely find a way to make this work for your use case + existing use cases.

[stephenafamo]

It should also be possible to extract the raw type from the *Value 🙏🏾

[bobf]

You can use switch to extract the raw type, or if you already know what type it is, you can use getT:

https://www.jetzig.dev/documentation/sections/data/value

[stephenafamo]

You can use switch to extract the raw type, or if you already know what type it is, you can use getT:

https://www.jetzig.dev/documentation/sections/data/value

Thanks 👍🏾