mruoss
Is it okay to implement Kino.Render for Map?
Hey there
The title basically says it all. Here’s what I would like to do in kino_k8s. I’d like to render maps that are (look like) Kubernetes resources as YAML markdown. And maybe later render maps that are lists of Kubernetes resources as table. Unfortunately, these are regular maps, not structs. I fear conflicts if multiple libs do the following. Or is this safe to do?
defimpl Kino.Render, for: Map do
def to_livebook(resource)
when is_map_key(resource, "apiVersion") and
is_map_key(resource, "kind") and
not is_map_key(resource, "items") do
"""
```yaml
#{Ymlr.document!(resource)}
```
"""
|> Kino.Markdown.new()
|> Kino.Render.to_livebook()
end
def to_livebook(resource), do: Kino.Output.inspect(resource)
end
Marked As Solved
jonatanklosko
Hey, I don’t think we should be implementing Kino.Render for any built-in data types outside of kino, because doing that would lead to conflicts sooner or later. Unless k8s returns a struct, I think the user should call |> KinoK8s.resource() or similar to convert map to kino markdown (and the smart cell can do that for them).
Also Liked
nulltree
Yeah, tbh I never worked with Kino or smart cells so far and am a bit out of my depth regarding best practices here, just wanted to introduce the idea of a ‘newtype’ / ‘type wrapper’ as I could see multiple implementations conflicting. So far wrapping the map in the struct and then render the structs implementation seems reasonable for my limited understanding, but am sure others with more experience can chime in. ![]()
True. ![]()
mruoss
Oh okay yes, that is more feasible. Gotta think about that…
mruoss
In any case thanks your input.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








