SelectoComponents

Alpha software. Expect API and behavior changes while the core LiveView package continues to settle.

selecto_components provides Phoenix LiveView components for building interactive query UIs on top of selecto.

It is the package you use when you want users to:

What It Includes

Requirements

Installation

def deps do
  [
    {:selecto_components, ">= 0.4.7 and < 0.5.0"},
    {:selecto, ">= 0.4.5 and < 0.5.0"},
    {:selecto_db_postgresql, ">= 0.4.3 and < 0.5.0"},
    {:selecto_mix, ">= 0.4.4 and < 0.5.0"}
  ]
end

Then run the recommended integration task:

mix deps.get
mix selecto.components.integrate
mix assets.build

That wires:

Minimal Usage

SelectoComponents.Explorer is now the preferred render surface.

Current migration note:

defmodule MyAppWeb.ProductLive do
  use MyAppWeb, :live_view
  use SelectoComponents.Form

  alias MyApp.SelectoDomains.ProductDomain
  alias MyApp.Repo

  def mount(_params, _session, socket) do
    selecto = ProductDomain.new(Repo)

    views = [
      {:detail, SelectoComponents.Views.Detail, "Detail", %{}},
      {:aggregate, SelectoComponents.Views.Aggregate, "Aggregate", %{}},
      {:graph, SelectoComponents.Views.Graph, "Graph", %{}}
    ]

    {:ok, assign(socket, get_initial_state(views, selecto))}
  end

  def render(assigns) do
    ~H"""
    <.live_component module={SelectoComponents.Explorer} id="product-explorer" {assigns} />
    """
  end
end

Config-Driven Explorer

You can also hand Explorer a smaller config struct while keeping the current parent LiveView compatibility boot path:

config = %SelectoComponents.Explorer.Config{
  id: "products",
  selecto: ProductDomain.new(Repo),
  views: [
    SelectoComponents.Views.spec(:detail, SelectoComponents.Views.Detail, "Detail", %{}),
    SelectoComponents.Views.spec(:aggregate, SelectoComponents.Views.Aggregate, "Aggregate", %{}),
    SelectoComponents.Views.spec(:graph, SelectoComponents.Views.Graph, "Graph", %{})
  ],
  title: "Products Explorer",
  presentation: %{timezone: "America/New_York"}
}

The current runtime still expects the parent LiveView to own state/event setup. Explorer.Config is the first host-facing config seam, not a full replacement for that compatibility path yet.

Common Add-Ons

You can start from Explorer and progressively add host-app integrations.

Compatibility note:

Saved Views

Use a host module that persists saved views and assign it to the LiveView.

Typical generation path:

mix selecto.gen.saved_views MyApp.SavedView MyApp.SavedViewContext

Exported Views

Use SelectoComponents.ExportedViews when you want signed iframe/embed snapshots of current views.

Email And Scheduled Exports

Assign these modules when you want the Export tab to send or manage exports:

assign(socket,
  export_delivery_module: MyApp.ExportDelivery,
  scheduled_export_module: MyApp.ScheduledExports,
  scheduled_export_context: scoped_context
)

The host app owns actual delivery and scheduling. selecto_components stays scheduler-neutral.

Recommended execution model: use Oban (or another worker system) to run due scheduled exports via SelectoComponents.ScheduledExports.Service.run_scheduled_export/3.

Extension Views

Map views and other extension-provided view systems are merged from domain extensions rather than hard-coded into the package.

Custom View Systems

selecto_components supports external view packages through SelectoComponents.Views.System.

That is the contract used when you want to publish a package like:

and register it into a host LiveView with SelectoComponents.Views.spec/4.

Status

Current 0.4.x scope:

Demos And Tutorials