Component API

[mhanberg]

The Component API is definitely getting better, but I don't think it's all the way there.

Things I'd like to see are

• slots
• ability to pass data from a component to the inner content (or a slot, inner_content is basically a default slot)
• Magic to make aliasing component modules easier.

Please use this discussion thread to discuss things you like about components, question, or any changes you'd like to propose (functions, syntax, features, etc).

[hfjallemark]

What are you thinking around making the aliasing the components modules easier? Right now the component API is a bit verbose for my taste. I think what I'd ideally like is are a bunch of components files inside a components folders.

So instead of:

# flex.ex
defmodule MyAppWeb.Components.Flex do
  use Temple.Component

  render do
    div class: "flex #\{@class}" do
      @inner_content
    end
  end
end

# index.html.exs
alias MyAppWeb.Components.Flex

c Flex, class: "justify-between items-center", id: "arnold" do
  div do: "Hi"
  div do: "I'm"
  div do: "Arnold"
  div do: "Schwarzenegger"
end

we'd have:

# flex.html.exs
div class: "flex #\{@class}" do
  @inner_content
end

# index.html.exs
flex class: "justify-between items-center", id: "arnold" do
  div do: "Hi"
  div do: "I'm"
  div do: "Arnold"
  div do: "Schwarzenegger"
end

If it's possible to write your own macro to do that I guess that would be fine, but it would be a nice alternative syntax to support natively I think! The majority of my use cases are simply extracting reusable HTML widgets into separate files. Usually I have some app-global components that are reused everywhere and sometimes I also have some view-local components that are only used in the current view. It would be nice if both cases could be supported side-by-side!

[mhanberg]

Which part of the API are you finding verbose? The component definition or the component usage?

[mhanberg]

The syntax that you show (that was previously supported) adds complexity to the implementation and uncertainty to the usage. I don't think I'll be considering adding support for that syntax, but I'll denote some of the the drawbacks here.

• Determining location of component
  • needs convention or configuration.
• Fuzzy boundaries.
  • The boundaries of components were hard to reason. The components were inlined, so one could access the call site's local variables and assigns (@foo from the call site). This is not what a user would expect.
• Compilation
  • Compilation is tricky when you're not using normal modules. I was seeing long compile times or stale files.

The pros of the current approach are basically the opposites of the drawbacks, but I'll list them here

• Explicit usage: you pass the c keyword a module and it renders that component.
• Boundaries of code are the same as normal view partials, which is the same as normal Elixir modules
• Since they're just modules, the compiler can easily see if they're stale and recompile and take advantage.

[mhanberg]

My idea for auto-aliasing component might be a helper like

# my_app_web.ex
defmodule MyAppWeb do
  #...
  def view do # or live_view, or live_component, etc
    # ...
    alias_components MyAppWeb.Component, "my_app_web/components"
  end
  # ...
end

This would be a small helper to navigate a directory and be able to cobble together the module based on the prefix and the file name. This would be a one time add as long as you follow a convention that you set for yourself.