Forem: Mykolas Mankevicius

Phoenix LiveComponent Provider Pattern

Mykolas Mankevicius — Sat, 31 Jan 2026 16:46:38 +0000

If you've worked with React, you've probably used the Provider pattern. It's a component that wraps children and provides them with data via context.
In Phoenix LiveView, we can achieve something similar using LiveComponent's :let directive combined with assign_async.

The Problem

I had a product detail page that needed to show similar products. The naive approach would be to load them in the parent LiveView's mount:

def mount(params, _session, socket) do
  product = get_product!(params)

  # Blocking the mount with a sync search operation 🙈
  {:ok, similar_products} = Search.similar_products(product.id, limit: 12)

  socket
  |> assign(:product, product)
  |> assign(:similar_products, similar_products)
  |> ok()
end

Two problems here:

Blocking mount - the search delays the entire page render
Scattered concerns - similar products logic lives in the parent LiveView

The Provider Pattern

Instead, I created a "provider" component that handles its own data loading and exposes the result to its children via :let.

The Provider (LiveComponent):

defmodule MarkoWeb.Components.SimilarProducts.Provider do
  use MarkoWeb, :live_component

  @impl LiveComponent
  def update(assigns, socket) do
    {%{product_id: product_id, limit: limit}, assigns} =
      Map.split(assigns, [:product_id, :limit])

    socket
    |> assign(assigns)
    |> assign_async(:search, fn ->
      {:ok, result} = Search.similar_products(product_id, limit: limit)
      {:ok, %{search: result}}
    end)
    |> ok()
  end

  @impl LiveComponent
  def render(assigns) do
    ~H"""
    <div id={@id}>
      <div :if={@search.loading}>
        <%= if @loading == [] do %>
          <.loading />
        <% else %>
          {render_slot(@loading)}
        <% end %>
      </div>

      <div :if={@search.ok? && Enum.any?(@search.result.hits)}>
        {render_slot(@inner_block, %{items: @search.result.hits, query: @search.result.query})}
      </div>

      <div :if={@search.ok? && Enum.empty?(@search.result.hits)}>
        <%= if @no_results == [] do %>
          <.no_results />
        <% else %>
          {render_slot(@no_results)}
        <% end %>
      </div>
    </div>
    """
  end

  defp loading(assigns) do
    ~H"""
    <Loading.spinner />
    """
  end

  defp no_results(assigns) do
    ~H"""
    <p>No results</p>
    """
  end
end

The key line is {render_slot(@inner_block, %{items: @search.result.hits, query: @search.result.query})}.

By passing a map, you control exactly what the provider exposes. Need to add more data later? Just add another key.

The Component Module:

defmodule MarkoWeb.Components.SimilarProducts do
  use MarkoWeb, :component

  # === Convenience components ===

  attr :product, Product, required: true
  attr :limit, :integer, required: true
  slot :loading
  slot :no_results

  def grid(assigns) do
    ~H"""
    <.provider :let={context} product={@product} limit={@limit}>
      <:loading :for={slot <- @loading}>{render_slot(slot)}</:loading>
      <:no_results :for={slot <- @no_results}>{render_slot(slot)}</:no_results>
      <.grid_inner {context} />
    </.provider>
    """
  end

  # === Provider (for custom rendering) ===

  attr :id, :any, default: nil
  attr :product, Product, required: true
  attr :limit, :integer, required: true
  slot :inner_block, required: true
  slot :loading
  slot :no_results

  def provider(assigns) do
    ~H"""
    <.live_component
      :let={context}
      module={__MODULE__.Provider}
      id={@id || id(:similar_products_provider, @product.id)}
      product_id={@product.id}
      limit={@limit}
      loading={@loading}
      no_results={@no_results}
    >
      {render_slot(@inner_block, context)}
    </.live_component>
    """
  end

  # === Inner presentation ===

  defp grid_inner(assigns) do
    ~H"""
    <ul class="grid grid-cols-2 gap-4 sm:grid-cols-4">
      <li :for={item <- @items}><ProductUI.card product={item} /></li>
    </ul>
    """
  end
end

Usage

For most cases, you don't even need to know about the provider:

# Grid layout - just use it
<SimilarProducts.grid product={@product} limit={12} />

# Custom loading/empty states - still simple
<SimilarProducts.grid product={@product} limit={12}>
  <:loading><ProductUI.skeleton_grid count={12} /></:loading>
  <:no_results><EmptyState.explore_more /></:no_results>
</SimilarProducts.grid>

# Custom rendering? Reach for the provider
<SimilarProducts.provider :let={%{items: items, query: query}} product={@product} limit={4}>
  <SimilarProducts.grid items={items} />
  <a href={~p"/search?#{query}"}>See all results</a>
</SimilarProducts.provider>

Why This Works

Simple things are simple - <SimilarProducts.grid product={@product} limit={12} />
Complex things are possible - provider exposes full visual control when needed
Self-contained async - the provider owns its data fetching
Extensible - need more data? Add a key to the context map

This is essentially React's Context Provider pattern, but in LiveView. The product detail page went from managing similar products loading to simply declaring where they should appear. Much cleaner.

This post was written with the help of AI, but I curate and review everything thoroughly. The ideas, code, and opinions are all mine.

Refactoring Phoenix Components

Mykolas Mankevicius — Sat, 31 Jan 2026 09:58:10 +0000

Refactoring Chat Bubbles in Phoenix LiveView: From Inline to Composable

Inline LiveView components have a way of growing organically until suddenly you're staring at duplicated styling logic everywhere. Here's how we refactored our chat bubbles into something composable.

The Problem

We had chat bubbles scattered across our codebase with duplicated styling and inconsistent APIs:

# Before: Inline styling in chat_ui.ex
defp left_bubble(assigns) do
  ~H"""
  <div class="flex flex-col gap-1">
    <div class="flex items-end gap-2.5">
      <.link navigate={~q"/:locale/shop/#{@user}"} class="shrink-0">
        <UserUI.avatar user={@user} variant={:h_6} class="shrink-0" />
      </.link>
      <div class={[
        @variant == :default && "bg-gray-100 after:border-r-gray-100",
        @variant == :offer && "min-w-[265px] bg-dark-primary text-inverted after:border-r-dark-primary",
        "relative flex w-fit flex-col rounded-lg rounded-bl-none p-2",
        "after:content-[''] after:border-t-[1em] after:border-r-[1em] after:absolute after:bottom-0 after:left-0 after:h-0 after:w-0 after:-translate-x-1/2 after:border-t-transparent"
      ]}>
        {render_slot(@inner_block)}
      </div>
    </div>
    <div class="ml-8">
      <Text.caption text={@timestamps} class="text-secondary" />
    </div>
  </div>
  """
end

This pattern was repeated for right_bubble/1 with mirrored styling. The main issue: business domain logic tied directly to styling. Variants like :default and :offer are domain concepts, but here they're mixed with CSS classes and layout decisions. Changing how an "offer" looks means hunting through conditionals.

The Solution: Extract a Reusable Component

1. Define Clear Attributes and Slots

defmodule MarkoUI.Components.ChatBubble do
  use MarkoUI, :component

  attr :side, :string, required: true, values: ["left", "right"]
  attr :color, :string, default: "default", values: ["default", "purple"]

  slot :inner_block, required: true
  slot :affix
  slot :caption

  @spec bubble(map()) :: Rendered.t()
  def bubble(assigns) do
    ~H"""
    <div data-side={@side} class="group/bubble flex items-end gap-2 data-right:flex-row-reverse">
      <div class="shrink-0">
        {render_slot(@affix)}
      </div>

      <div
        style={bubble_style(@color)}
        class="min-w-[264px] bg-[var(--color-bg)] border-[var(--color-border)] relative w-fit rounded-t-lg border group-data-left/bubble:rounded-r-lg group-data-right/bubble:rounded-l-lg"
      >
        {render_slot(@inner_block)}
        <.bubble_tail side={@side} />
        <div :if={@caption != []} class="absolute bottom-0 translate-y-full pt-1 group-data-left/bubble:left-0 group-data-right/bubble:right-0">
          {render_slot(@caption)}
        </div>
      </div>
    </div>
    """
  end
end

Named slots (affix, inner_block, caption) give callers flexibility. The bubble_tail/1 private component handles that fiddly CSS triangle—it uses the same CSS custom properties so colors stay in sync automatically.

2. Use CSS Custom Properties for Theming

Instead of conditional classes like @variant == :default && "bg-gray-100", we use inline custom properties:

defp bubble_style(color) do
  case color do
    "default" -> "--color-bg: #ffffff; --color-border: #030303; --color-hover: #f6f5f7; color: #030303;"
    "purple" -> "--color-bg: #5454DF; --color-border: #ffffff; --color-hover: #6969e0; color: #ffffff;"
    "black" -> "--color-bg: #030303; --color-border: #ffffff; --color-hover: #2b2b2b; color: #ffffff;"
  end
end

The bubble tail inherits colors automatically, and adding new variants is just one function clause.

3. Create Composable Sub-Components

@spec content(map()) :: Rendered.t()
def content(assigns) do
  ~H"""
  <div class="rounded-lg p-2">
    {render_slot(@inner_block)}
  </div>
  """
end

attr :label, :string, default: nil
attr :rest, :global, include: ~w(href navigate patch method download name value disabled)
slot :inner_block, required: true

@spec action(map()) :: Rendered.t()
def action(%{rest: rest} = assigns) do
  assigns =
    assign(assigns, :class,
      "peer bg-[var(--color-bg)] border-[var(--color-border)] text-body-1 block w-full border-t py-3 text-center group-data-left/bubble:rounded-br-lg group-data-right/bubble:rounded-bl-lg hover:bg-[var(--color-hover)]"
    )

  if rest[:href] || rest[:navigate] || rest[:patch] do
    ~H"""
    <.link class={@class} {@rest}>
      {@label || render_slot(@inner_block)}
    </.link>
    """
  else
    ~H"""
    <button type="button" class={@class} {@rest}>
      {@label || render_slot(@inner_block)}
    </button>
    """
  end
end

The action/1 component uses attr :rest, :global to accept navigation attributes, then conditionally renders a <.link> or <button>. It inherits colors from the parent via those CSS custom properties.

4. Refactor the Consumer

Now chat_ui.ex becomes much cleaner:

# After: Using the ChatBubble component
defp left_bubble(assigns) do
  ~H"""
  <ChatBubble.bubble side="left" color={variant_to_color(@variant)}>
    <:affix>
      <.link navigate={~q"/:locale/shop/#{@user}"}>
        <UserUI.avatar user={@user} variant={:h_6} class="shrink-0" />
      </.link>
    </:affix>
    <ChatBubble.content>
      {render_slot(@inner_block)}
    </ChatBubble.content>
    <:caption>
      <ChatBubble.caption text={@timestamps} />
    </:caption>
  </ChatBubble.bubble>
  """
end

defp variant_to_color("default"), do: "purple"
defp variant_to_color("offer"), do: "black"

ChatBubble handles styling, ChatUI handles business logic, and variant_to_color/1 bridges domain concepts to presentation.

5. Build Higher-Level Abstractions

Now we can create domain-specific components on top:

@spec system_bubble(map()) :: Rendered.t()
def system_bubble(assigns) do
  ~H"""
  <ChatBubble.bubble side="left" color="default">
    <:affix>
      <div class="size-6 bg-brand-3-primary rounded-full">
        <SVG.icon name="other-logo-marko-icon" class="size-full" />
      </div>
    </:affix>

    <ChatBubble.content>
      <div class="flex flex-col gap-2">
        <Text.caption :if={@title} bold text={@title} />
        {render_slot(@inner_block)}
      </div>
    </ChatBubble.content>
    {render_slot(@content)}

    <:caption>
      <ChatBubble.caption text={@caption || DateTimeHelper.chat_time(DateTime.utc_now())} />
    </:caption>
  </ChatBubble.bubble>
  """
end

Fixed affix, optional title, auto-generated timestamp—all the system message defaults baked in.

Using `data-*` Attributes for Variant Styling

A pattern worth highlighting:

<div data-side={@side} class="group/bubble flex items-end gap-2 data-right:flex-row-reverse">

Tailwind's data-* variants let you conditionally style without runtime class concatenation. Combined with group/bubble, children can respond to parent state:

class="group-data-left/bubble:rounded-br-lg group-data-right/bubble:rounded-bl-lg"

Less logic, less data down the socket.

Key Takeaways

Extract when you see a clear pattern — sometimes it's best to wait for 3 variants to see the underlying API. We needed system_bubble and that forced the decision.
Use slots for flexibility — named slots let consumers customize specific parts.
CSS custom properties beat class explosion — one style function instead of scattered conditionals.
Separate domain from presentation — a mapping layer like variant_to_color/1 keeps business concepts out of your styling code.
Layer your abstractions — base component (ChatBubble) → domain component (system_bubble).
data-* attributes for variants — cleaner than runtime class concatenation.
Component libraries are documentation — a dedicated page showing all variants catches regressions and exposes design flaws.

P.S.

You really don't need complicated setups for testing components. Simple LiveViews with a few handlers is all it takes. Storybook and friends are beautiful abstractions, but often overkill. These test pages don't have to be pretty—they'll expose flaws in your component design when you feel resistance using them. :D

One more thing: you'll notice I use string variants instead of atoms throughout. Atoms are great for Elixir code, but they're limited in number and never garbage collected—no need to eat into that space for component APIs. Plus side="left" is one character less than side={:left}, and you can copy-paste to React/Vue/Svelte if you're into that. :D

P.S.S

This post was written with the help of AI, but I curate and review everything thoroughly—the ideas, code, and opinions are all mine.

Tailwind Icon Mask Plugin for phoenix liveview

Mykolas Mankevicius — Thu, 10 Jul 2025 11:48:21 +0000

Here's an update to this article How to integrate Tabler Icons into your Phoenix project

The article goes over the general implementation and you should read it to understand what is happening.

In this post I'm simply providing and improved solution after running into some bugs.

TL;DR; here's the helper:

import { readFileSync, readdirSync } from 'fs'
import { basename, join } from 'path'
import type { KeyValuePair } from 'tailwindcss/types/config'

export type Icon = {
  name: string
  fullPath: string
}

export type IconValues = KeyValuePair<string, Icon>

export const getIconValues = (iconsDir: string, transformName?: (name: string) => string) => {
  const values: IconValues = {}

  for (const file of readdirSync(iconsDir)) {
    // Skip non-SVG files
    if (!file.endsWith('.svg')) continue
    const fullName = basename(file, '.svg')
    const name = transformName ? transformName(fullName) : fullName
    values[name] = { name, fullPath: join(iconsDir, file) }
  }

  return values
}

export const getIconCSS = (value: string | Icon, values: IconValues) => {
  let name = ''
  let fullPath = ''
  let strokeWidth = '1.5'

  if (typeof value === 'string') {
    const hasModifier = value.includes(',')
    const iconName = hasModifier ? value.split(',')[0] : value
    const customStrokeWidth = hasModifier ? value.split(',')[1] : '1.5'
    const icon = values[iconName] || {}
    name = iconName
    fullPath = icon.fullPath
    strokeWidth = customStrokeWidth
  } else {
    name = value.name
    fullPath = value.fullPath
  }

  if (!fullPath) {
    return {}
  }

  const content = readFileSync(fullPath)
    .toString()
    .replace(/\r?\n|\r/g, '')
    .replace(/<svg([^>]*)>/g, (_match, attributes: string) => {
      // Remove width and height attributes (with preceding whitespace) from the svg opening tag, and no where else
      const cleanedAttributes = attributes.replace(/\s+width="[^"]*"/g, '').replace(/\s+height="[^"]*"/g, '')
      return `<svg${cleanedAttributes}>`
    })
    .replace(/\sstroke-width="[^"]*"/, ` stroke-width="${strokeWidth}"`)

  const varName = `--icon-url-${name}`

  return {
    [varName]: `url('data:image/svg+xml;utf8,${content}')`,
    '-webkit-mask': `var(${varName})`,
    mask: `var(${varName})`,
    'mask-repeat': 'no-repeat',
    'background-color': 'currentColor',
    'vertical-align': 'middle',
    'horizontal-align': 'middle',
    display: 'inline-block',
    width: '1.25rem',
    height: '1.25rem'
  }
}

and here is how to use it:

import plugin from 'tailwindcss/plugin'
import { getIconValues, getIconCSS } from './plugin-icons-utils'
import { join } from 'path'
import type { IconValues, Icon } from './plugin-icons-utils'

module.exports = {
  content: [
    './ts/**/*.{js,ts}',
  ],
  plugins: [
    plugin(({ matchComponents }) => {
      const path = './svg/icons/custom'
      const values: IconValues = getIconValues(join(__dirname, path), (key) => key.replace('custom-', ''))

      matchComponents({ custom: (value: string | Icon) => getIconCSS(value, values) }, { values })
    }),
  ]
}

The plugin does a few things:

First off it fixes a bug where width and height, were being removed from everything inside the .svg content. For e.g. stroke-width would become stroke- and so forth.
it supports the custom- prefix icons that are in your ./svg/icons/custom directory
it also supports dynamic values to change the stroke-width, for e.g: custom-[ship,2] will produce and icon custom-ship with the stroke-width: 2 this is a trick to provide masks with some customisation, you could come up with your own syntax if you need more changes, something like custom-[ship,sw:2,lc:y] and then parse each modifier to adjust as you see fit.
you can also provide a name transform, for e.g. my custom icons have a prefix custom- so the full path is something like svg/icons/custom/custom-ship.svg if you wouldn't provide a name transformer you would need to type custom-custom-ship as the match component takes the first part as the custom: as a prefix for the value.
Allows to easily add other component libraries. Change the path and the prefix matchComponents({ custom: (value: string | Icon) the prefix is the custom name in this part, you could have feather/hero or whatever you'd like.

Building an Interactive Tag Input Component with Phoenix LiveView

Mykolas Mankevicius — Mon, 24 Feb 2025 23:35:35 +0000

I've been exploring ways to create reusable UI components with Elixir and Phoenix LiveView. Here's my latest creation: a flexible, interactive tag input component that combines server-side rendering with client-side interactivity using LiveView Hooks.

What We're Building

The tag input component allows users to:

Add items by typing and pressing Enter or Tab
Remove items with a button or backspace (when enabled)
Enforce a maximum item limit
Detect and animate duplicate entries
Provide autocomplete suggestions (optional)
Submit items as part of a form

Here's a quick demo of what it looks like:

<FormUI.root for={@form} id="tag-form" phx-change="validate" phx-submit="save">
  <FormUI.Tags.input
    field={@form[:free_range]}
    label="Anything Goes (List Input)"
    description="This is a tag input field. You can add as many items as you want. Press `Enter` or `Tab` to add a new item. Press backspace or click on `x` to remove an item."
  />
  <FormUI.Tags.input
    field={@form[:limited_options]}
    label="Limited Options (List Input, with options)"
    description="This is a tag input field with limited options. You can only add items from the list. Press `Enter` or `Tab` to add a new item. Press backspace or click on `x` to remove an item. Press `ESC` to close the dropdown. Note: this uses popover Api and Anchor API. Soon I will add simple absolute position option, as well as a FloatingUI option. This searches for contains rather than starts_with"
    options={@basic_options}
    search_type="contains"
  />
  <FormUI.Tags.input
    field={@form[:languages]}
    label="Languages (List Input, with options)"
    description="An example language select input"
    options={@language_options}
  />
  <FormUI.actions>
    <.button phx-disable-with="Saving...">Save</.button>
  </FormUI.actions>
</FormUI.root>

The Architecture

This component is split into three main parts:

Elixir Components: Phoenix components for server-side rendering and form integration
JavaScript Hooks: LiveView Hooks for client-side interactivity
CSS: TailwindCSS classes for styling (customizable)

Server-Side: Elixir Components

The Elixir side uses two main modules:

ListInputUI.Headless.List: Defines the core list structure with components like root, item, input, and options these component don't assume anything about your styles
ListInputUI.Field: Provides a form-aware wrapper with labels, error handling and styling

Client-Side: LiveView Hooks

Two JavaScript hooks power the interactivity:

ListInputHook:
- Manages the core list functionality
- Adds/removes items
- Enforces max items and duplicate detection
- Triggers change events for LiveView updates
ListInputOptionsHook:
- Manages the autocomplete dropdown
- Filters options based on input
- Handles keyboard navigation (Arrow keys, Enter)
- Highlights matching text using CSS Highlights API

Integration with LiveView

The hooks integrate seamlessly with LiveView by:

Attaching to DOM elements via phx-hook
Dispatching change events that trigger LiveView form updates
Using hidden inputs to submit data with forms

Next Steps

I plan to enhance this component by:

Improving accessibility with ARIA attributes
Show examples for searchable options in dropdown from the server
Create a video of how i've done this.

You can find the full source code on @Gumroad, don't worry it's free if you choose so.

My Experience with Elixir Development

Mykolas Mankevicius — Fri, 24 Jan 2025 14:35:01 +0000

I've been doing Elixir development full-time for nearly two years now.

I love the language and the tools we have as a community. The creators and maintainers are doing a superb job of supporting, maintaining, and creating new things.

All of the following are just some observations I have coming from a different ecosystem.

LSP - The Thing That Makes Your Editor Do Wonders

We have great news that there is a team now working on an official LSP for Elixir. Please go and support these people as I am - even a $1 donation to all three people will go a long way if we get enough of us to donate.

Here's the blog post with more details

Until then, for VS Code users, just use elixir-ls, and if you're using asdf, make sure to have a .tool-versions file in your project's root folder. It will work some of the time.

Project Setup

With LiveView 1.0, we finally got this, which is great to have in the docs. But it would be even nicer on the front page of Phoenix:

curl https://new.phoenixframework.org/myapp | sh

It's something, but I personally think that Ash framework has something much better, and I hope that Phoenix will adopt it as well.

Adding Dependencies

Much better now with Igniter:

mix igniter.install some_library

But without Igniter, it's this:

Find the dependency
Copy-paste the requirement into mix.exs
Run mix deps.get

Which feels very convoluted for something so simple.

Dependency Setup

Much better now with Igniter, if the library supports it.

Otherwise, it's:

Hope the documentation covers the setup
If not, search the web for setup instructions
If nothing is on the web, try asking in forum/slack/discord
If no luck, wait a few years and maybe you'll join a team where someone has made it work

Try setting up ex_cldr with gettext with a backend and interpolation.
There are so many things to figure out, it's not even funny.

I'm lucky I'm working with people who have done it, so I can copy-paste many things into my own projects.

I don't know why, but this feels very complicated at times.

The Docs

While very good in content, they are hard to understand as a beginner coming from platforms like Laravel, Nuxt, Next, or Astro.

LiveView

While it's an amazing technology, pray you don't need any complex components or infinite scroll with position restoration.

You'll soon learn about hooks and how difficult they are to work with if you don't understand JavaScript at an intimate level.

I don't have that problem as I love JavaScript and don't mind creating hooks. But it's night and day compared to working with something like Vue/React and their ecosystems.

Code Organization

It's challenging, and I still don't know how to do it properly. In the projects that I'm working on with Ash, this becomes much clearer.

Components

Delete core_components.ex and use one of these to save some time:

Other Resources

Overall

You need to learn a lot to really have a nice starting point. You have to read/watch many blog posts, Reddit threads, and YouTube videos about setup and related topics to ensure you're well-prepared to start.

Look at something like Laravel - a lot of information is right on the front page, and the docs connect many concepts. I understand that Taylor does this for a living; I just wish that our leaders could work on these things and make money from them too.

Again, I'm just noting these things down in hopes that people will prove me wrong and tell me what I've missed.

Phoenix LiveView, nested .inputs_for

Mykolas Mankevicius — Wed, 22 Jan 2025 09:31:50 +0000

TIL: You can nest .inputs_for in Phoenix LiveView forms to make inputs visually coherent.

Note: This is a simplified example.

<.inputs_for :let={profile} field={@form[:profile]}>
  <Fields.text field={profile[:first_name]} />
  <.inputs_for :let={images} field={@form[:images]}>
    <Fields.avatar field={images[:avatar]} />
  </.inputs_for>
</.inputs_for>

Cleaner LiveView Pipes

Mykolas Mankevicius — Tue, 21 Jan 2025 14:22:50 +0000

I like my pipes and i like em clean!

@impl LiveView
def mount(%{"edition" => id}, _session, socket) do
  edition = Festival.get_edition_by_id!(id, actor: user(socket))

  socket
  |> assign_edition(edition, false)
  |> assign(patch_path: ~q"/:locale/admin/edition/#{edition}/edit")
  |> ok()
end

Over the few years of using LiveView I've found this to be a nice improvement to the codebase.

defmodule SocketHelpers do
  @moduledoc """
  A collection of functions to help express pipes when processing live view responses.
  """

  alias Phoenix.LiveView.Socket

  @spec ok(Socket.t()) :: {:ok, Socket.t()}
  def ok(%Socket{} = socket), do: {:ok, socket}

  @spec noreply(Socket.t()) :: {:noreply, Socket.t()}
  def noreply(%Socket{} = socket), do: {:noreply, socket}

  @spec cont(Socket.t()) :: {:cont, Socket.t()}
  def cont(%Socket{} = socket), do: {:cont, socket}

  @spec halt(Socket.t()) :: {:halt, Socket.t()}
  def halt(%Socket{} = socket), do: {:halt, socket}

  @spec user(Socket.t()) :: map() | nil
  def user(%Socket{assigns: %{current_user: current_user}}), do: current_user

  @spec locale(Socket.t()) :: atom() | nil
  def locale(%Socket{assigns: %{locale: locale}}), do: locale

  @spec notify_parent(Socket.t(), any()) :: atom() | nil
  def notify_parent(%Socket{} = socket, message) do
    send(self(), message)
    socket
  end
end

Take the SocketHelpers module from above and import it into your YourApp.live_view/0 helper:

def live_view do
  quote do
    use Phoenix.LiveView,
      layout: {OctafestWeb.Layouts, :app}

    importSocketHelpers

    alias Phoenix.LiveView

    unquote(html_helpers())
  end
end

Phoenix LiveView is slot empty?

Mykolas Mankevicius — Tue, 10 Dec 2024 12:44:11 +0000

Here's a simple function to check if the slot is empty, where empty can mean.

No slot provided
Slot provided but has only whitespace

defp slot_empty?(slot) do
  case slot do
    [] ->
      true

    slots when is_list(slots) ->
      not Enum.any?(slots, fn slot ->
        case slot do
          %{inner_block: inner_block} when is_function(inner_block) ->
            try do
              {:ok,
                inner_block.(%{}, nil)
                |> Phoenix.HTML.html_escape()}
            rescue
              _ -> :error
            end
            |> case do
              {:ok, html} ->
                html
                |> Phoenix.HTML.safe_to_string()
                |> String.trim()
                |> Kernel.!=("")

              _ ->
                true
            end

          _ ->
            false
        end
      end)

    _ ->
      true
  end
end

Example usage:

slot :inner_block

@spec heading(assigns :: map()) :: Rendered.t()
def heading(assigns) do
  ~H"""
  <header :if={not slot_empty?(@inner_block)} class="grid gap-4 pb-8 text-left">
    <%= render_slot(@inner_block) %>
  </header>
  """
end

Hope this helps.

Tailwind CSS plugin for hover/active states

Mykolas Mankevicius — Sat, 02 Nov 2024 10:54:51 +0000

The problem:

I need a card with a main action on hover of the card, but it also can have secondary actions, and working on those actions shouldn't cause the main card styles to change

The solution:

I've created a plugin for tailwind

Here is the link to the gist with all the required info:

https://gist.github.com/Neophen/2f512ace1e7182e5346076333e4a0fdc

Better LiveView Hooks with Typescript

Mykolas Mankevicius — Tue, 29 Oct 2024 08:25:26 +0000

Ok so sometimes you need typescript for your hooks.
And then basically you need to type every single method in the hook.
You have to do bindings in mounted so that you could use the functions in callbacks and so forth.
It becomes really tiring and verbose really quickly.

Solution?

LiveViewHook class

Link to gist

Here's a simple example of how to use it:

import { LiveViewHook } from './live_view_hook'

class HeightTrackerHook extends LiveViewHook {
  private resizeObserver: ResizeObserver | null = null

  mounted() {
    this.resizeObserver = new ResizeObserver(this.setHeightProperty)
    this.resizeObserver.observe(this.el)
  }

  beforeDestroy() {
    this.resizeObserver?.unobserve(this.el)
  }

  private setHeightProperty = ([entry]: ResizeObserverEntry[]) => {
    document.documentElement.style.setProperty(this.requiredAttr('data-height-var'), `${entry.contentRect.height}px`)
  }
}

export default HeightTrackerHook.createViewHook()

Hope this helps!
Take care!

When teaching give students a visual aid

Mykolas Mankevicius — Tue, 18 Jun 2024 06:03:44 +0000

TL;DR;

to get the code and password join the community on ash-casts

Teaching is hard

Teaching is always hard especially when you are teaching abstract concepts and not something manual like woodworking.

When teaching programming you want to enlist as many ways of displaying the process as possible so that students could grasp the concept more tangibly.

Enlist visual aids

Livebook is an amazing tool for teaching elixir, but it might still be difficult to portray how data is changing or what is actually happening.

For example you're teaching data transformations in Elixir:

And you write the code like this:

But that is difficult to visualise, so you as the teacher can add visual aid things, which might be too difficult for students to understand at the moment, but they don't need to know how it works.

So adding |> Point.show() to the end of the pipeline now outputs a nice image:

Which is much easier to grasp.

Hope this helps in your future endeavours!

Based on this youtube video:

Visualization [Grokin'] Learn Elixir w/ Bruce Tate

Add clamped sizes to TailwindCSS

Mykolas Mankevicius — Mon, 27 May 2024 07:34:25 +0000

Here's a little snippet i use to easily create responsive spacing/text sized.

const remToPX = (rem) => rem * 16
const pxToRems = (px) => px / 16

const formatNumber = (num) => parseFloat(num.toFixed(3)).toString()

const clamped = (minPx, maxPx, minBp, maxBp) => {
  const slope = (maxPx - minPx) / (maxBp - minBp)
  const slopeVw = formatNumber(slope * 100)
  const interceptRems = formatNumber(pxToRems(minPx - slope * minBp))
  const minRems = formatNumber(pxToRems(minPx))
  const maxRems = formatNumber(pxToRems(maxPx))
  return `clamp(${minRems}rem, ${slopeVw}vw + ${interceptRems}rem, ${maxRems}rem)`
}
const MIN_VIEWPORT_WIDTH = 400
const MAX_VIEWPORT_WIDTH = 1000
const clampPx = (minPx, maxPx) => clamped(minPx, maxPx, MIN_VIEWPORT_WIDTH, MAX_VIEWPORT_WIDTH)
const clampRem = (minRem, maxRem) => clamped(remToPX(minRem), remToPX(maxRem), MIN_VIEWPORT_WIDTH, MAX_VIEWPORT_WIDTH)

And i use it like so in the tailwind.config.js

    fontSize: {
      '32_48': [
        clampPx(32, 48),
        clampPx(38, 56),
      ],
    },
    spacing: {
        '32_60': clampPx(32, 60),
        '32_64': clampPx(32, 64),
    }

Which allows me to create responsive spacing based on viewport width like so:

It's all based on this excellent work:

https://github.com/AleksandrHovhannisyan/fluid-type-scale-calculator

Don't forget to like and share please! :D

Forem: Mykolas Mankevicius

Phoenix LiveComponent Provider Pattern

The Problem

The Provider Pattern

Usage

Why This Works

Refactoring Phoenix Components

Refactoring Chat Bubbles in Phoenix LiveView: From Inline to Composable

The Problem

The Solution: Extract a Reusable Component

1. Define Clear Attributes and Slots

2. Use CSS Custom Properties for Theming

3. Create Composable Sub-Components

4. Refactor the Consumer

5. Build Higher-Level Abstractions

Using data-* Attributes for Variant Styling

Key Takeaways

P.S.

P.S.S

Tailwind Icon Mask Plugin for phoenix liveview

Building an Interactive Tag Input Component with Phoenix LiveView

What We're Building

The Architecture

Server-Side: Elixir Components

Client-Side: LiveView Hooks

Integration with LiveView

Next Steps

My Experience with Elixir Development

LSP - The Thing That Makes Your Editor Do Wonders

Project Setup

Adding Dependencies

Dependency Setup

The Docs

LiveView

Code Organization

Components

Other Resources

Overall

Phoenix LiveView, nested .inputs_for

Cleaner LiveView Pipes

Phoenix LiveView is slot empty?

Tailwind CSS plugin for hover/active states

Better LiveView Hooks with Typescript

LiveViewHook class

When teaching give students a visual aid

Teaching is hard

Enlist visual aids

Add clamped sizes to TailwindCSS

Using `data-*` Attributes for Variant Styling