Nick Stalter | Lead SeniorSoftware Engineer

Phoenix LiveView: Offline-ish list with localStorage and a follow-up event

Sun, 15 Feb 2026 00:00:00 +0000

On mobile, locking the screen often drops the WebSocket or suspends the tab. When the user unlocks and returns to your LiveView, the process may have been torn down and mount runs again. If mount always shows a loading spinner and refetches from the server, the user sees a full refresh every time they check their list—annoying when they’re in the store and opening the app every few minutes.

This post shows a small pattern to make a list (or any data-heavy view) feel “offline-ish”: cache a serializable snapshot in localStorage, have the client push it to the server in a follow-up event (not in connect params—that can blow the URI length limit), and show it immediately while still refetching in the background. If decode or staleness check fails, you fall back to a normal load.

I used this for the shopping list in OnRotation; the same idea applies to any LiveView that remounts often on mobile.

1. Cache shape

Store a JSON object with whatever the template needs to render, plus a timestamp for staleness:

entries – array of items (e.g. id, display_name, quantity, category, checked, …)
Any other assigns the template uses (e.g. selected_week_start, week_meal_names, item_key_to_meal_names)
cached_at – ISO8601 timestamp so the server can ignore cache older than your TTL (e.g. 15 minutes)

Use a single key per origin (e.g. myapp_shopping_list) if you have one list per user.

2. Server: push cache after loading or updating

Whenever you assign the list (or related) data, push a serializable payload to the client so the hook can write it to localStorage. No structs or DateTime in the payload—plain maps and strings.

defp build_cache_payload(assigns) do
  %{
    "entries" => Enum.map(assigns.entries || [], &entry_to_cache/1),
    "selected_week_start" => assigns.selected_week_start && Date.to_iso8601(assigns.selected_week_start),
    "cached_at" => DateTime.utc_now() |> DateTime.to_iso8601()
    # ... other keys the template needs
  }
end

defp push_cache(socket) do
  push_event(socket, "cache_shopping_list", build_cache_payload(socket.assigns))
end

Call push_cache(socket) at the end of handle_info(:load_plan, socket) and after every handle_event that updates the list (toggle, add, delete, etc.).

3. Client: hook to write cache

A hook that listens for the event and stores the payload:

const CACHE_KEY = "myapp_shopping_list"

const ShoppingListCacheHook = {
  mounted() {
    this.handleEvent("cache_shopping_list", (payload) => {
      try {
        localStorage.setItem(CACHE_KEY, JSON.stringify(payload))
      } catch (_) {}
    })
  }
}

Mount the hook on an element in your LiveView (e.g. a hidden div so it’s present when the list is rendered).

4. Client: send cache in a follow-up event (not connect params)

Do not put the cache in LiveSocket’s params. Those end up in the connection URL and can hit URI length limits (often 4–8KB), causing “request URI too long” errors and even infinite redirect/error loops when the list is large.

Instead, have the same hook that writes the cache push an event to the server when it mounts. The payload goes in the WebSocket message body, so size is not an issue:

const ShoppingListCacheHook = {
  mounted() {
    this.handleEvent("cache_shopping_list", (payload) => {
      try {
        localStorage.setItem(CACHE_KEY, JSON.stringify(payload))
      } catch (_) {}
    })
    // Send cache to server in a follow-up event to avoid URI length limit
    try {
      const cached = localStorage.getItem(CACHE_KEY)
      if (cached) this.pushEvent("restore_cached_list", { cache: cached })
    } catch (_) {}
  }
}

Keep params: { _csrf_token: csrfToken } (or a simple static object); no cache there.

5. Server: apply cache when the event arrives

Handle the event: if you’re still loading and the cache is valid, apply it and set your loading flag to false. You still run the refetch (e.g. send(self(), :load_plan) in mount); when it completes, assign fresh data and call push_cache again.

@cache_ttl_seconds 900  # 15 minutes

def mount(_params, _session, socket) do
  socket = assign_defaults(socket)
  send(self(), :load_plan)
  {:ok, socket}
end

def handle_event("restore_cached_list", %{"cache" => cache_str}, socket) when is_binary(cache_str) do
  if socket.assigns.plan_loading? do
    case try_apply_decoded_cache(socket, cache_str) do
      {:ok, updated} -> {:noreply, assign(updated, :plan_loading?, false)}
      :skip -> {:noreply, socket}
    end
  else
    {:noreply, socket}
  end
rescue
  _ -> {:noreply, socket}
end

def handle_event("restore_cached_list", _params, socket), do: {:noreply, socket}

defp try_apply_decoded_cache(socket, cache_str) do
  case Jason.decode(cache_str) do
    {:ok, decoded} when is_map(decoded) ->
      if cache_fresh?(decoded), do: {:ok, apply_cached_assigns(socket, decoded)}, else: :skip
    _ -> :skip
  end
end

defp cache_fresh?(decoded) do
  case decoded["cached_at"] do
    nil -> false
    iso when is_binary(iso) ->
      case DateTime.from_iso8601(iso) do
        {:ok, dt, _} -> DateTime.diff(DateTime.utc_now(), dt, :second) <= @cache_ttl_seconds
        _ -> false
      end
    _ -> false
  end
end

Decode and apply: build entries (and any derived assigns like entries_by_section) from the decoded map. If anything fails (decode, missing keys, bad types), leave the socket as-is and let the refetch show the real data. No need for elaborate validation—fail fast and fall back.

Edge cases

No cache – Behave as today: loading spinner, then load.
Stale cache – Ignore if cached_at is older than your TTL; load as normal.
Decode / structure error – Ignore cache and refetch. Defensive decode keeps bad or tampered data from breaking the view; the server remains the source of truth.

Security note

The cache is only for UX: show something immediately. The server always re-fetches and scopes data by the authenticated session. Don’t trust the cache for authorization. For a shopping list or similar, storing it in localStorage is fine; for more sensitive data, consider whether you want it on the client at all.

Summary

After each load or mutation, push_event(..., "cache_...", payload) with a serializable snapshot.
A JS hook writes that payload to localStorage and, on mount, reads it and pushEvent("restore_cached_list", { cache }) so the server gets it in a WebSocket message (not connect params—avoids URI length limits).
Server handles "restore_cached_list": if still loading and cache is valid (decode + TTL), apply it and set loading to false.
Mount always triggers a refetch; when it completes, assign fresh data and push the new cache.

With a short TTL (e.g. 15 minutes), users get an instant list when they reopen the app after a brief lock, and the list still refreshes in the background so it stays accurate.

For more on hooks and storage, see the earlier post Phoenix LiveView with localStorage or sessionStorage; this one focuses on reconnect/mount and sending the cache in a follow-up pushEvent (not connect params) to avoid both the full refetch and URI length limits.

OnRotation: Technical Architecture of a Phoenix LiveView Meal Planning App

Sat, 14 Feb 2026 00:00:00 +0000

OnRotation is a weekly meal planning app built with Phoenix and LiveView. I’ve written about the product story before; this post focuses on the technical architecture: how the app is structured, how data flows, and the patterns we rely on to keep it simple and maintainable.

Tech Stack

Phoenix 1.8 with LiveView
Ecto + PostgreSQL for persistence
Tailwind CSS v4 for styling (CSS variables, no config file)
Req for HTTP (no HTTPoison/Tesla)
Resend for transactional email (magic links, invites)
Sentry for error tracking

Quality tooling: Credo, Dialyzer, SoBelow (security), all wired into mix precommit.

Architecture Overview

The app follows a context-based structure. Core domains:

Accounts – users, households, invites, magic-link auth
Meals – meal library, curated meals, meal packs
Plans – weekly plans and plan entries
ShoppingLists – per-household shopping list with plan-derived items
Blog – public blog with Earmark-based body processing

Almost all domain data is scoped by household. A user belongs to one household; meals, plans, and shopping lists are all keyed by household_id. That keeps queries straightforward and authorization simple.

The Scope Pattern

We use an OnRotation.Accounts.Scope struct to represent the caller’s context:

defstruct user: nil, household: nil

phx.gen.auth gives us current_scope, not current_user. The scope carries both user and household, so controllers and LiveViews can consistently pass current_scope into contexts. Context functions take scope or household_id as the first argument and scope all queries by household.

This avoids leaking user-only logic into contexts and keeps “who is acting” and “on which household” explicit.

Routing and Pipelines

We use separate pipelines and live sessions for different auth levels:

Public – marketing, blog, sitemap, robots (browser_and_seo)
Auth routes – log-in (magic link), registration
Authenticated – plan, meals, shopping list, feedback (live_session :authenticated)
Blog admin – create/edit blog posts (require_blog_author)
Meal pack admin – manage curated meal packs (require_meal_pack_admin)
Admin – metrics dashboard (require_admin)

The API pipeline (/api/v1) accepts JSON and uses Bearer token auth. It’s used by the Android app; web users stay in LiveView.

Authentication

We’re privacy-focused: no passwords, magic links only, and Simple Analytics for basic analytics instead of tracking-heavy alternatives. No cross-site tracking, no ad networks.

Web users sign in via magic links. The flow:

User enters email.
We create or find the user and send a tokenized link (Resend).
User clicks the link; we validate the token and establish a session.

For the mobile API:

Client calls POST /api/v1/auth/magic-link with email.
User receives the link and opens it in a browser; we redirect to a page that calls the API to exchange the token for a Bearer token.
Client stores the Bearer token and sends it on subsequent requests.

Both flows end up with a session token; web uses cookies, API uses Authorization: Bearer <token>.

Data Model

The main entities:

Household – one per account; owns meals, plans, shopping list
Meal – name, recipe_url, main_ingredients, extras, tags, complexity (1–3)
Plan – one per week per household (week_start_date = Monday)
PlanEntry – links plan to meal, with day_index (0=Mon … 6=Sun) and position for multiple meals per day
ShoppingListEntry – per-household; entries come from plan merge or manual “extras”

Meals, plans, and shopping lists are always queried with household_id in the WHERE clause.

Shopping List: Plan Merge and Categorization

The shopping list has two sources of items:

Plan-derived – parsed from main_ingredients and extras of meals in the current week’s plan
Manual extras – user-added items (e.g. paper towels, milk)

merge_plan_into_list/2 takes the current week’s plan, parses ingredients into segments (comma/semicolon), normalizes them into item_keys for grouping, and upserts into ShoppingListEntry by (household_id, item_key). Existing rows are never deleted by the merge—only added or updated.

Categorization is done by ShoppingLists.Categorizer: whole-word keyword matching against produce, meat/seafood, cheese/dairy, pantry, and a default “items” bucket. Priority order matters (e.g. “egg noodles” matches pantry before cheese) so we can sort the list in a sensible shopping order.

LiveView and UI

Core features (plan, meals, shopping list) are LiveView pages. We use:

Streams for large, appendable lists to avoid memory growth
Functional components (CoreComponents) for forms, buttons, layout
Colocated JS hooks when we need client behavior (e.g. theme toggle in localStorage)

All LiveView templates start with <Layouts.app flash={@flash} ...> and receive current_scope from the live_session so they can pass it into context calls.

Design System

Colors and typography live in DESIGN.md and CSS variables (var(--onrotation-primary), etc.). Light/dark themes use data-theme="light" and data-theme="dark"; we also support “system” via prefers-color-scheme. Theme choice is persisted in localStorage and applied before paint when possible to avoid flash.

Transactional emails share the same layout and brand colors, with inline styles for email client compatibility.

Blog and Content

The blog is a separate context (OnRotation.Blog) with published posts, tags, and an author-scoped admin. Body content is stored as Markdown in the database and rendered with Earmark at request time. A BodyProcessor runs after Earmark to replace {{meal:N}} shortcodes with rendered meal cards—so authors can embed curated meals in posts, and logged-in users can add them to their library in place.

The blog admin is a LiveView (BlogAdminLive) behind a require_blog_author plug. Authors get a list view, create/edit with autosave draft, tag management, and a preview that matches the public layout. Public routes are controller-based: index (optionally filtered by tag), show by slug, and an RSS feed at /blog/feed.xml. The sitemap includes blog posts for SEO. Slugs are derived from titles; tags are many-to-many and filterable on the index.

API for Mobile

/api/v1 exposes resources for meals, plans, and plan entries. The API uses the same context functions as the web app; the only difference is auth (Bearer tokens) and response format (JSON). A plug assigns household_id from the authenticated user so controllers can call contexts like Meals.list_meals(household_id, opts) without extra logic.

Quality and Consistency

We enforce consistency with:

One alias per line – no alias Foo.{Bar, Baz}
@moduledoc and @spec on public functions
No maybe_ prefix – use descriptive names instead
mix precommit – format, Credo, SoBelow, Dialyzer, tests

The AGENTS.md and .cursor/rules files document these conventions for humans and AI-assisted workflows.

Summary

OnRotation is a Phoenix app where:

Household-scoped contexts and a Scope struct keep authorization and data access clear.
LiveView drives the web UX with streams and functional components.
A small JSON API under /api/v1 serves mobile with the same business logic.
Magic links power both web and mobile auth.
A token-based design system and precommit checks keep the codebase consistent and maintainable.

If you’re building something similar—household/multi-tenant, LiveView-heavy, with a mobile API—this architecture is a solid starting point. The main lesson: invest in scoping and context boundaries early; they make everything else easier.

Try OnRotation at onrotation.app — start with our Starter Pack and plan your week in minutes.

Beyond the Whiteboard: Why We Built OnRotation

Tue, 10 Feb 2026 00:00:00 +0000

We built OnRotation out of something simple: our love of cooking and the desire to make everyday life run a little smoother.

Like many home cooks, we already had a rotation of go-to meals we loved. We enjoyed experimenting with them, tweaking flavors, and trying new ideas. But weeknights still brought the same questions: What are we making? Do we have everything? Did we remember to thaw the meat?

Too often, that led to wandering the grocery store aisles without a plan, buying things we didn’t need, or giving in to last-minute takeout.

A Little About Us

We’re a couple based in Columbus, Ohio, sharing our home with two cats and two dogs who are always very interested in what’s for dinner. I’m a software engineer, and my wife manages a special diet for her epilepsy—which means meal planning isn’t just about convenience for us, it’s essential.

We both love cooking. It’s one of our favorite ways to spend time together, experimenting with flavors and finding new ways to make our go-to meals even better. But managing a specific dietary plan while juggling busy schedules? That’s where things got complicated.

One of the biggest challenges was finding alternatives to our favorite meals that fit the dietary requirements. We’d discover a great substitute, make it once, then completely forget about it weeks later.

The Whiteboard Era

So we started keeping track—first in a spreadsheet, listing every meal we’d successfully made, what worked, what didn’t, and when we last had it. Then we’d reference that spreadsheet when filling out our weekly whiteboard.

Yes, a literal whiteboard on our fridge. We had the days of the week written out, and every Sunday we’d plan our meals and fill it in. We’d jot notes like “pull out chicken Tuesday” to remind ourselves to thaw meat ahead of time.

It worked… but it was clunky. We were juggling two systems just to answer one question: What are we eating this week?

We found ourselves thinking, There has to be a better, easier, and more fun way to do this.

So we created one.

What OnRotation Does

OnRotation takes years of using that trusty whiteboard and combines it with our love of cooking, experimenting, and prepping. It’s designed to help you:

Plan Your Week

Build your own library of meals—your actual go-to dishes, not someone else’s recipes. Then drag them into a 7-day calendar. See your entire week at a glance, know exactly what’s for dinner each night, and eliminate the daily “what should we make?” debate.

Track Your Rotation

See when you last made each meal and how often you cook it. This helps you keep things fresh and varied—no more accidentally making the same thing three weeks in a row, or forgetting about that great recipe you tried last month.

Shop with Intention

Your shopping list is automatically generated from your weekly plan. No more wandering the store wondering what you need. Just open the app, check off items as you shop, and know you have everything for the week.

Manage with Your Household

You can invite members to your household to share in meal planning, shopping lists, and maintaining your collection of meals.

Add What You Actually Need

Because meal planning isn’t the only reason you go to the store, OnRotation lets you add extra items—paper towels, milk, dog food—right alongside your meal ingredients. One list for everything.

Who It’s For

While we built this for ourselves, we quickly realized how powerful it could be for anyone who:

Manages dietary restrictions - Whether it’s epilepsy, celiac, diabetes, or allergies, keeping track of what works is crucial
Cooks the same meals regularly - You’re not looking for new recipes every week, you just want to organize the ones you already love – Those looking for new ideas - You can browse Meal Packs to get ideas for dinners that you may have not had in a while or something completely new
Wants to reduce food waste - Buying only what you need for planned meals means less throwing away spoiled food
Needs to eliminate decision fatigue - The daily “what’s for dinner” question is exhausting

Families especially benefit from this. Kids can see what’s coming up for the week (no more surprise complaints at dinner time), and everyone can prepare mentally for what’s ahead.

Getting Started is Easy

We created Meal Packs—curated collections of common meals like Tacos, Spaghetti, Grilled Chicken, and Burgers. Add our Starter Pack of 25 meals with one click, then customize every single one to match how your family actually makes it.

Swap store-bought pasta for homemade. Add your secret taco seasoning blend. Change “grilled chicken” to “baked chicken thighs” because that’s what you actually cook. The meal packs give you a foundation to build on, so you’re not staring at a blank screen wondering where to start.

Within minutes, you’ll have a library that reflects your family’s actual cooking style—not someone else’s idea of what you should eat.

Why It Matters

When we started planning our meals for the week, everything changed. Meal planning gave us peace of mind. It saved time at the store, cut down on food waste, and helped us stick to the way of eating that works best for us.

Instead of guessing what sounded good each night, we knew exactly what we were making and what we needed. We shopped with purpose, used what we already had in the pantry or freezer, and avoided those “cheating” or “ordering in” days that can sneak up when life gets busy.

Because meal planning shouldn’t feel like a chore—it should feel like a tool that gives you back your time, your energy, and your peace of mind.

Try OnRotation

We’re excited to finally share what started as a whiteboard on our fridge and turned into something we use every single day.

OnRotation is live at onrotation.app. Start with our Starter Pack, customize it to your style, and take control of your weekly cooking.

We’d love to hear what you think. What features would make meal planning easier for you? What’s your biggest challenge with planning meals? Let us know—we’re just getting started, and your feedback shapes where we go next.

Creating an Accordion in Phoenix Liveview

Mon, 04 Dec 2023 00:00:00 +0000

Creating an Accordion in Phoenix Liveview

Hello friends, I wanted to spend some time and write about converting an HTML/JS accordion to Phoenix’s functional components in LiveView. We will go through what functional components are, slots, attrs and how to open/close without really writing any Javascript.

Background

I wanted to start with an HTML/JS based accordion so we can go through just how powerful LiveView is

A basic HTML/Javascript accordion can look something like this:

  <div class="max-w-md mx-auto">
    <div class="border rounded overflow-hidden">
      <!-- Accordion Item 1 -->
      <div class="border-b">
        <button
          class="w-full text-left py-2 px-4 font-semibold bg-gray-200 hover:bg-gray-300 focus:outline-none"
          onclick="toggleAccordion('content1')"
        >
          Section 1
        </button>
        <div id="content1" class="hidden p-4">
          <!-- Your content for Section 1 goes here -->
          Lorem ipsum dolor sit amet, consectetur adipiscing elit.
        </div>
      </div>

      <!-- Accordion Item 2 -->
      <div class="border-b">
        <button
          class="w-full text-left py-2 px-4 font-semibold bg-gray-200 hover:bg-gray-300 focus:outline-none"
          onclick="toggleAccordion('content2')"
        >
          Section 2
        </button>
        <div id="content2" class="hidden p-4">
          <!-- Your content for Section 2 goes here -->
          Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris.
        </div>
      </div>

      <!-- Add more accordion items as needed -->

    </div>
  </div>

With the ability to toggle open/close:

  <script>
    function toggleAccordion(id) {
      const content = document.getElementById(id);
      content.classList.toggle('hidden');
    }
  </script>

That is all fine and dandy, but what if we want to reuse the accordion someplace else? We can convert this into a functional component!

Functional Components

Functonal components allow us to reuse components across various facets of our application, including LiveView and non-LiveViews(some people call them dead views).

You can learn more about the CoreComponents in the Phoenix Docs We will be using core_components.ex for our example.

We will then expand on the accordion to take in slots and attributes. Attributes are, as their name implies, attributes to pass to our component. These attrs are Slots are markup that we want our component to render in some way.

Hopefully this all makes more sense later on.

Getting Started

We can generate a new Phoenix app: mix phx.new --no-ecto my_app. Once finished, there is a new core_components.ex that was generated. These core components are all functional components and LiveView provides a few already(buttons, forms, etc.)

Let’s start up the app with iex -S mix phx.server

We need a canvas to paint our accordion onto, so we should create a new liveview

Inside router.ex add a new live route:

live "/hello", MyAppLive

Now create the new LiveView file at ./my_app/lib/my_app_web/live/my_app_live.ex

And paste the following in my_app_live.ex:

defmodule MyAppWeb.MyAppLive do
  use Phoenix.LiveView
  import MyAppWeb.CoreComponents

  def render(assigns) do
    ~H"""
      <h1>Hello there</h1>
    """
  end
end

If we visit http://localhost:4000/hello we should see our Hello there.

Converting HTML/JS Accordion to Functional Component

Conversion is pretty straightforward in our case, as HEEX templates are already HTML.

First we need to define our accordion component inside lib/my_app/components/core_components.ex and paste our original accordion without the JavaScript and onclick. We will re-add the click functionality later.

  def accordion(assigns) do
    ~H"""
      <div class="max-w-md mx-auto">
        <div class="border rounded overflow-hidden">
          <!-- Accordion Item 1 -->
          <div class="border-b">
            <button
              class="w-full text-left py-2 px-4 font-semibold bg-gray-200 hover:bg-gray-300 focus:outline-none"
              onclick="toggleAccordion('content1')"
            >
              Section 1
            </button>
            <div id="content1" class="p-4">
              <!-- Your content for Section 1 goes here -->
              Lorem ipsum dolor sit amet, consectetur adipiscing elit.
            </div>
          </div>

          <!-- Accordion Item 2 -->
          <div class="border-b">
            <button
              class="w-full text-left py-2 px-4 font-semibold bg-gray-200 hover:bg-gray-300 focus:outline-none"
              onclick="toggleAccordion('content2')"
            >
              Section 2
            </button>
            <div id="content2" class="p-4">
              <!-- Your content for Section 2 goes here -->
              Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris.
            </div>
          </div>

          <!-- Add more accordion items as needed -->

        </div>
      </div>
    """
  end

We can now use our accordion in our LiveView! All we need to do is replace our <h1>Hello there</h1> with <.accordion></.accordion>. We should now see our accordion.

Adding Slots and Attributes to our Functional Component

Having hard coded markup specific to this accordion is undesired if we want to reuse it in other places. We can use slots and attrs to render mark up being passed into the component.

Slots and attrs need to be defined above our accordion definition and will look like the following:

  slot :content do
    attr :title, :string
    attr :id, :string
  end

  def accordion(assigns) do
    ~H"""
    <div class="max-w-md mx-auto">
      <div class="border rounded overflow-hidden">
        <%= for content <- @content do %>
          <div class="border-b">
            <button
              class="w-full text-left py-2 px-4 font-semibold bg-gray-200 hover:bg-gray-300 focus:outline-none"
            >
              <%= content.title %>
            </button>
            <div id={content.id} class="p-4">
              <%= render_slot(content) %>
            </div>
          </div>
        <% end %>
      </div>
    </div>
    """
  end

Here, we are using a named slot called content that has a few attributes that will help us when we add the open/close functionality back.

We need to update our LiveView to use the new accordion functionality:

    <.accordion>
      <:content title="my title" id="my-title">
        <h1>Hello there</h1>
      </:content>
      <:content title="my second title" id="my-second-title">
        <h1>Hello there x2</h1>
      </:content>
      <:content title="my third title" id="my-third-title">
        <h1>Hello there x3</h1>
      </:content>
    </.accordion>

Currently, we cannot open/close it, as we are not using the JavaScript that came with it. So let’s do that now!

Replacing JavaScript with LiveView JS

Okay, so, this is technically cheating as we are still using JavaScript. LiveView has a module called JS. This module is full of utility functions that will call the JavaScript for us without us having to write a script for it.

We need to add a phx-click to the button in the accordion:

phx-click={JS.toggle(to: "##{content.id}")}

JS.toggle() will

Show or hide elements based on visibility, with optional transitions

Condiontally Show/Hide by default

If we wanted to start with the accordion panels closed by default we can use an attr called start_closed

Add the attr to the content slot:

  slot :content do
    attr :title, :string
    attr :id, :string
    attr :start_closed, :boolean
  end

And add a condtional style to the accordion panel:

<div id={content.id} class="p-4" style={if content[:start_closed], do: "display: none;"}>

Note how we have to access the start_closed, currently we cannot set default values for slot attributes

Finally, add the attribute to some of the accordion’s content slots:

<:content title="my second title" id="my-second-title" start_closed={true}>
<:content title="my third title" id="my-third-title" start_closed={true}>

We have parts of the accordion that are hidden by default while retaining the ability to toggle as needed!

Conclusion

Functional components are super powerful and allow us to reuse components across our applcation. Slots and attributes can be somewhat intimidating at first but hopefully this helped to bring you the confidence you need.

Phoenix Liveview using LocalStorage or SessionStorage

Thu, 14 Apr 2022 00:00:00 +0000

Phoenix Liveview using LocalStorage or SessionStorage

Sometimes we want to fetch or store data in localStorage or sessionStorage, we can fetch/store this data using LiveView hooks. These hooks allow for interoperability with JavaScript and grant us the ability to interact with a liveview during its lifecycle.

For storing the data, we will call a JavaScript hook inside a liveview function to store the value of a counter.

For fetching the data, we will be using the reconnected hook to fetch data from localStorage or sessionStorage. In this post we will be using sessionStorage as the data is wiped when we close the tab. If you wanted to persist the data, localStorage is what you are looking for. Both storages use the same function getItem(key) where we provide a key which hopefully has the values we are looking for.

For more information regarding sessionStorage and localStorage see the Mozilla Docs

Cloning the Demo Project

Let’s clone the demo Phoenix LiveView app. The main branch will only contain the minimal amount of setup without implementing any hooks:

git clone git@github.com:distortia/counter_example.git

For the complete solution check out the complete branch.

Setting up the Hooks

NOTE: All hooks need to be defined above the following line let liveSocket = new LiveSocket("/live", Socket, {params: {_csrf_token: csrfToken}})

Initializing our empty hooks object to be populated later:

let hooks = {}

We need to add our hooks to the liveSocket:

let liveSocket = new LiveSocket("/live", Socket, {
  params: {_csrf_token: csrfToken},
  hooks: hooks,
})

Saving State on Button Click

To save the state of our counter on button click we need to write a custom hook.

In app.js, we are going to create a hook called saveCount:

hooks.saveCount = {
  mounted() {
    this.handleEvent("saveCount", ({ count }) =>
      sessionStorage.setItem("count", count)
    )
  }
}

saveCount uses the mounted hook so it gets attached as the component is mounted.

For the handle_event function we use a new function called push_event which will invoke the JavaScript hook we called saveCount

def handle_event("inc", _session, socket) do
  count = socket.assigns.count + 1
  socket = socket |> assign(count: count)
  {:noreply, push_event(socket, "saveCount", %{count: count})}
end

To wire up our button we need to add a unique ID as well as the hook:

<button id="inc-button" phx-click="inc" phx-hook="saveCount">Increment</button>

We should now see the value of count being incremented in sessionStorage as well as on the page

Restoring state on Reconnection

To restore the state from sessionStorage we need to create a new hook that I will call restore:

hooks.restore = {
  mounted() {
    count = sessionStorage.getItem("count")
    this.pushEvent("restore", {count: count})
  }
}

This hook will call our restore event in the liveview which looks like:

def handle_event("restore", %{"count" => count}, socket) do
  count = String.to_integer(count)
  socket = socket |> assign(count: count)
  {:noreply, socket}
end

NOTE: Values in sessionStorage are strings and we need to properly convert to the correct type

We do need to handle cases where we have no value in the sessionStorage, we can do that by explcitly handling nil values above the original handle_event call:

def handle_event("restore", %{"count" => nil}, socket), do: {:noreply, socket}

def handle_event("restore", %{"count" => count}, socket) do
  count = String.to_integer(count)
  socket = socket |> assign(count: count)
  {:noreply, socket}
end

In order to actually call the restore hook we need to add a unique ID to the element and attach our hook to it:

<section class="phx-hero" id="page-live" phx-hook="restore" >

We now have a way to restore data from sessionStorage or localStorage into our LiveView!

To test this out, we can go into the developer settings and manually add key-value pair to sessionStorage

example: count: 100

When we refresh the page, the counter should reflect the value in the sessionStorage

Conclusion

This is how to store and restore data in a LiveView using Hooks and sessionStorage. If you found it helpful, reach out on twitter or share with your friends!

If you are interested in working with elixir every day, come join my remote team at InfluxData!

Thanks!

Custom Honeybadger filters for Tokens

Fri, 24 Sep 2021 00:00:00 +0000

Hey All, it has been quite a long time since my last post. I apologize for that. Today, I will be keeping things short and sweet.

Custom Honeybadger filters for Tokens

Honeybadger is a service for “Exception, uptime, and cron monitoring, all in one place”. At InfluxData, we use this service to monitor our application and recieve notifications when things go wrong. Sometimes, we receive a bit too much information, such as Bearer Tokens.

Leaking tokens is a serious security concern. Bad faith actors can use that token to manipulate your systems or systems you are connected to. Once a token has been exposed, you need to fix the issue and rotate your tokens.

In this case, we want to redact any token going to Honeybadger.

Fortunately, the Honeybadger Elixir Repo has an easy way for us to create a custom filters. Let’s do that now.

defmoudle MyApp.MyFilter do
  use Honeybadger.Filter.Mixin

  def filter_error_message(message) do
    Regex.replace(~r/(Token|Bearer) [^"]+/, message, "\\1 redacted")
  end
end

This will filter error messages before being sent to Honeybadger and check for Token <token> or Bearer <token> and replace them with Token redacted. What is nice is that this covers Tesla, HTTPoison and probably any other HTTP library you pick. All the error messages are just strings. That means we can expect escaped strings and can capture the values up until we hit the closing ".

So, let’s write a few tests for these scenarios:

NOTE: We are looking for typical Bearer <token> and Token <token>. Error messages are truncated as they are quite large.

defmodule MyApp.HoneybadgerFilterTest do
  use ExUnit.Case, async: true
  alias MyApp.HoneybadgerFilter

  describe "filter_error_message" do
    test "replaces general tokens" do
      token = "some.jwt.abc123"
      message = "[token: \"#{token}\"]"
      actual = HoneybadgerFilter.filter_error_message(message)
      assert actual =~ "[token: \"redacted\"]"
      refute actual =~ token
    end

    test "replaces bearer tokens" do
      token = "some.jwt.abc123"
      message = "{\"Authorization\", \"Bearer #{token}\"}"
      actual = HoneybadgerFilter.filter_error_message(message)
      assert actual =~ "{\"Authorization\", \"Bearer redacted\"}"
      refute actual =~ token
    end
  end
end

The tests will cover and probably any other HTTP library you pick.

Conclusion

Adding custom filters for Honeybadger can be very straightforward. With a little of regex(I am sorry), you can safely export errors without leaking tokens!

Thanks!

Nick

Introducing ProPollr.com

Mon, 03 Sep 2018 00:00:00 +0000

Hey everyone!

I have been hacking away on an idea for a week and finished it!

Introducing ProPollr.com!

What is ProPollr?

ProPollr is a realtime polling application that focuses on ease of use, realtime interactivity, and polling anonymity!

I came up with the idea as I was walking passed a group that was holding a retro. They were writing all of their responses onto sticky notes and walking up to the whiteboard to place them. That’s when it hit me. We know that anonymous feedback is honest feedback, so let’s capitalize on that!

What’s the Tech Stack?

This should come as no surprise, I am using

Elixir
Phoenix - I’ll touch on this in a minute.
Bulma - With Node-Sass for Brunch
Font Awesome 5 Pro - Awesome Icons!
Veil - I’ll touch on this in a minute as well.

Phoenix

Phoenix is a wonderful framework for composing web applications and API’s. Some of the amazing features that comes with Phoenix, are Channels and Presence.

Channels are a means to send and receive messages from sockets. There are a myriad of functionalities built in that allow you to incorporate realtime aspects with minimal code. With Channels, you can perform controller actions and broadcast to the specfied socket, you can listen for specific messages and reply with changes to state. An awesome use of sockets is the Drab Project.

I use sockets for realtime question and answers.

Presence is a newer feature of Phoenix that revolves around, well, presences. It’s biggest highlight is the ability to track and register process informatatin across the cluster. Presence has no single point of failure and no single source of truth. This is massive!

The main reason for me to use it, is to display the current number of Pollrs in a Sesh(a question session).

Veil

Veil is a wonderful passwordless authentication library. It is much easier to not have to worry about storing/salting/hashing/protecting passwords if you never check for one. This also makes the user experience that much simpler. The action for logging in is the same as creating an account. You get an email sent to your inbox and you click the link to authenticate. I find is very simple and easy to work with. Authentication is then handled to an encoded cookie that automatically gets checked and its TTL(Time to Live) extended.

So What is the Plan?

Propollr is open for use now.

My next steps, in no particular order:

Full Launch
Add extra features such as graphs and charts
Extra question categorization - So you can run things like retros
Setup CI/CD using Distillery

Conclusion

For me, the biggest win is the ability to take an idea and push something out in a week. It’s a wonderful feeling to release something new and already have a viable beta group to use it.

Feel free to check it out and submit some feedback!

Git Graveyard: Letscode - 2014

Sat, 18 Aug 2018 00:00:00 +0000

Welcome back to another post about my Git Graveyard. Today I want to look at a CLI(Command-line Interface) utility I worked on.

Let’s Code - CLI Utility for Opening Up Project Specific Programs - 2014

Let’s Code was intended to be a CLI that would open up specific programs that you need to get working on your project.

You would use it like letscode myproject. Let’s Code would then open your editor with your project, Trello/Jira, and can be configured to open up another other programs you need, like Slack.

Motivation

I was motivated to make getting into work easier. I was constantly switching between projects and various programs in order to do my work. I wanted to help my context switching out while trying to remain in the terminal as best I could.

The usage was pretty straightforward:

require 'thor'

module Letscode
    class CLI < Thor
        include Thor::Actions
        include Letscode

        #main method
        desc "start [PROJECT]", "To start a project, type 'letscode start [PROJECT]'"
        def start(project)
          get_project(project)
          process_keys
        end

        desc "config", "To config a project, please type 'letscode config'"
        def config
            config = get_config
            write_file config
        end

        desc "list", "Shows all projects in the config file."
        def list
           puts  "#{list_projects.to_yaml}"
        end

        desc "delete [PROJECT]", " To delete a file type 'letscode delete [PROJECT].'"
        def delete(project)
            config = read_file
            config.delete project
            write_file config
        end
    end
end

The various methods went out and did what you expect. Just follow up with a letscode myproject and you were ready to roll!

Reason for Abandoning

I abandoned this project as I switched jobs and had less context switching over all. As I reread the code I wrote and the direction it was going, I feel this project would have been a fun little utility.

Tech Stack

Ruby - I was getting more into rails at the time and wanted something familiar to work in.
Thor - toolkit for building powerful command-line interfaces in Ruby
Watir - A gem typically used for browser automation(mostly for testing)
ChromeDriver - chromium’s webdriver implementation for browser automation

Conclusion

All in all, I may want to revisit this utility. I have quite a bit of use for it as of late. The project I am working on has different repos for it’s umbrella apps and I have to switch between projects fairly regularly. As far as looking at my code, I am pleasantly surpised with past me. I managed to keep things coherent and readible.

I may end up porting this over to Elixir, it’s one of my favorite languages and has strong built in CLI Utilities with OptionParser

Git Graveyard: Alpaca - 2014

Wed, 15 Aug 2018 00:00:00 +0000

Hey all, I’ve seen some recent posts online around “Github Graveyard”. The premise of “Github Graveyard” is to reflect on old projects that end up abandoned. I know I have a few of these projects and wanted to start a new series for my projects. I’d also like to extend “Github Graveyard” to be “Git Graveyard” or “Project Graveyard”. I know GitHub is a big deal but we should not be narrowing the scope of these stories.

Alpaca - Fully Encrypted Chat Messaging System - 2014

Alpaca was intended to be a fully ecrypted(end-to-end) messaging application with a focus on security and ease of use. My original thought was to start as a web service to make everything work, then port over the neccessary pieces to mobile.

One of the key pieces I wanted, was to be completely unable to decrypt the communications and stay as an independent entity. As of late, it appears that no matter what social networks and media do, they always seemed to get sucked into some sort of mess.

Motivation

I came up with the idea for Alpaca as a way to better utilize chat apps and provide a more secure method for communication. At school, I was using a lot of Skype(gross) and Google Hangouts(Not much better). There wasn’t a huge demand for secured communication but I was trying to be proactive to better protect everyone. It wasn’t super easy to invite someone into a group chat and have real discussions about our project or homework.

Reason for Abandoning

I started Alpaca in college and ended up abandoning due to lack of time and apps like Telegram coming to the forefront. Telegram gets quite a bit of flak for it’s use in shadier activites. Maybe it was best that I never finished this project.

I fell short before doing the encryption.

Tech Stack

The tech stack was pretty simple back then,

Socket.io - Real time updating for the chat.
Mongodb - Easy storage for history, if desired.
Expressjs - Web Server
Sass + SkeletonUI - Simple and lightweight front end framework and tooling
Polymer or Angular - Never got around to integrating these into the site. I was experiencing a lot of Angluar 0.x - 1.x back in the day but Polymer offered something interesting with web components.

Conclusion

I feel pretty good about not finishing this project. With all the trouble that Telegram gets into from the shadier parts of the world, it is more trouble that it is worth. But I enjoyed looking back and my motivations and what I was thinking about back then.

Elixir EScripts vs Mix Run

Fri, 03 Aug 2018 00:00:00 +0000

Continuing on my last post as a write about a new service I am working on at work, I’d like to talk about EScripts.

What are EScripts? They are Elixir scripts in the form of an executable that you compile and run.

What are EScripts used for?

This is a great question! EScripts are compiled with all the Elixir code needed to run. Which means it’ll run on any machine that has Erlang installed. This means you can make an portable executable as a CLI(Command Line Interface).

If you are making a CLI application, such as a custom scaffolding based on inputs from the CLI, then EScripts are wonderful.

What are EScripts not used for?

While having a CLI can be a great thing, it does not make sense to port service code into EScripts. Service code, such as database seeding, migrating data, etc.

Phoenix does a great job at demonstrating this with it’s seed files.

EScripts are best suited for creating CLIs as stated in their docs. I have seen many use EScripts for what they should be using mix run my_script.exs for. Maybe the docs of Elixir is too great and they came across EScripts. Either way, I wanted to shed some light and help educate those that may be tempted to use an EScript.

My experience in using an EScript instead of `mix run`

In an attempt to get into the weeds of the situation, I created an EScript to read data from a file, parse/transform, and load it into my database.

Normally, I would have this as an .exs file or Elixir Script inside a bin folder. I would invoke the file as MIX_ENV=my_env mix run bin/my_script.exs. I have different databases for dev and prod. I know that all my prod/dev environments all have Elixir on them, so I do not have to worry about shipping an all-inclusive erlang executable.

With each EScript it needs to be compiled for the environment that it needs to run in. This is kind of tedious. Running MIX_ENV=prod mix escript.build and not remembering that last time you compile your script can bite you sometimes. I accidentally ran, what I thought was a prod EScript, in dev. I was confused for a little bit as to why my data was not in my prod database. Then it hit me, I compiled my EScript for dev, not prod

With mix run, I have to explicitly set my MIX_ENV to prod in order to run the script on my prod instance. There is a bit more verbosity with this setup and I feel that the process keeps you from making the mistake of running the right script in the wrong environment.

Conclusion

For most of your needs you should always pick mix run over EScripts. Both can be covered under your code coverage tool of choice. Both can be tested in the same manor. mix run is more verbose in it’s usage and for me, that’s a huge plus.

Nick Stalter | Lead SeniorSoftware Engineer

Phoenix LiveView: Offline-ish list with localStorage and a follow-up event

1. Cache shape

2. Server: push cache after loading or updating

3. Client: hook to write cache

4. Client: send cache in a follow-up event (not connect params)

5. Server: apply cache when the event arrives

Edge cases

Security note

Summary

OnRotation: Technical Architecture of a Phoenix LiveView Meal Planning App

Tech Stack

Architecture Overview

The Scope Pattern

Routing and Pipelines

Authentication

Data Model

Shopping List: Plan Merge and Categorization

LiveView and UI

Design System

Blog and Content

API for Mobile

Quality and Consistency

Summary

Beyond the Whiteboard: Why We Built OnRotation

A Little About Us

The Whiteboard Era

What OnRotation Does

Plan Your Week

Track Your Rotation

Shop with Intention

Manage with Your Household

Add What You Actually Need

Who It’s For

Getting Started is Easy

Why It Matters

Try OnRotation

Creating an Accordion in Phoenix Liveview

Creating an Accordion in Phoenix Liveview

Background

Functional Components

Getting Started

Converting HTML/JS Accordion to Functional Component

Adding Slots and Attributes to our Functional Component

Replacing JavaScript with LiveView JS

Condiontally Show/Hide by default

Conclusion

Phoenix Liveview using LocalStorage or SessionStorage

Phoenix Liveview using LocalStorage or SessionStorage

Cloning the Demo Project

Setting up the Hooks

Saving State on Button Click

Restoring state on Reconnection

Conclusion

Links

Custom Honeybadger filters for Tokens

Custom Honeybadger filters for Tokens

Conclusion

Introducing ProPollr.com

What is ProPollr?

What’s the Tech Stack?

Phoenix

Veil

So What is the Plan?

Conclusion

Links

Git Graveyard: Letscode - 2014

Let’s Code - CLI Utility for Opening Up Project Specific Programs - 2014

Motivation

Reason for Abandoning

Tech Stack

Conclusion

Git Graveyard: Alpaca - 2014

Alpaca - Fully Encrypted Chat Messaging System - 2014

Motivation

Reason for Abandoning

Tech Stack

Conclusion

Elixir EScripts vs Mix Run

What are EScripts used for?

My experience in using an EScript instead of `mix run`