Composability Patterns for Hologram - Looking for Your Ideas

I recently started a discussion about reactive patterns in Hologram, but I realized I need to step back and design the composability architecture first - the reactive patterns should fit within that broader framework.

Quick Context on Hologram

Hologram is a framework that compiles Elixir to JavaScript, letting you write isomorphic web applications entirely in Elixir. Components can run on both client and server.

Currently, a Hologram component is represented by a Component struct containing:

  • State - the component’s data
  • Emitted context - data passed down to child components
  • Next operations - instructions for what should happen next (e.g., “run action X”)

Components can define:

  • Actions - functions that run client-side and update local state
  • Commands - functions that execute on the server

However, don’t feel constrained by this - I’m open to completely different approaches.

The Challenge

We’ll likely need some reactive patterns - things like:

  • Memoization/derived state
  • Effects (Ă  la React’s useEffect)
  • Watchers (Ă  la Vue)

Or maybe something completely different! These are just examples from other frameworks.

In React, hooks provide elegant composability:

// Extract reusable logic
function useToggle(initialValue = false) {
  const [value, setValue] = useState(initialValue);
  const toggle = () => setValue(v => !v);
  return [value, toggle];
}

// Compose it:
function Panel() {
  const [isOpen, toggleOpen] = useToggle(false);
  
  return (
    <div>
      <button onClick={toggleOpen}>Toggle</button>
      <div>{isOpen ? 'Open' : 'Closed'}</div>
    </div>
  );
}

What I’m Looking For

How could actions, state operations, reactive patterns, and other patterns compose in Hologram?

Due to Elixir’s functional/immutable nature, the patterns will likely manifest differently than in React/Vue. That’s the interesting part!

Show me your ingenuity and creativity - every idea matters, no matter how unconventional or silly you think it is. Everything is on the table:

  • Function composition
  • Macros
  • Explicit or implicit namespacing
  • Flat keys
  • Mixins
  • Something else entirely?

Also worth noting: Hologram has compile-time access to the full call graph, which could potentially help solve this problem (though it doesn’t have to).

What patterns would you explore? Feel free to share anything from high-level ideas to concrete code examples or even full system designs.

10 Likes

I think you are thinking too much. Honestly, nobody else matters, it is your project, so do whatever your heart lead you to. If I were you, I will just pick the path that require the least amount of work, as long as it does not prevent you from picking a more adventurous path later. You can have breaking changes! you can have multiple APIs!

6 Likes

I always liked the idea of the reducer patterns introduced in Redux ans RTK myself. I didnt like all the plumbing that went into it sometimes, but the base premise of “starting state →input → new state” was simpler to reason about, and would also align with Elixir’s functional nature well IMO.

I also really liked Svelte’s writable and derived stores, as they were easy to compose inside a state module and expose only what I wanted exposed, so I could have a stateful reactive core that the presentation layer could bind to as needed.

In the end though, your leadership, preferences, and vision will have to be the deciding factor. For all the opinions you get on this question, you will naturally have a far better view of how it all fits together.

4 Likes

I am inclined to agree with this. Unless you’re going to copy an existing solution you have to accept that it’s going to take years of real-world use to nail down these APIs.

I find these discussions fun and helpful for nailing down my own beliefs (and finding out which of them hold up to scrutiny), but at the end of the day you have to iterate on something if you want to make progress.

I will see if I can come up with some thoughts, though, as I do think composition is important. Also remember that in a lot of these frameworks the components are the main unit of composition and features like Hooks or Signals are intended as a means to share logic across components (but they should still compose too, of course).

2 Likes

Bit off-topic for the thread but I’ll quickly respond.

While I would agree that following your heart/what feels right is generally a good way to go I also really like how Bart has been seeking feedback on things he feels might benefit from it :icon_biggrin:

It helps people feel like what they want matters and often leads to comments like this:

It’s something which plays a role in project confidence and helps create a deep and personal affiliation.

I would go as far as to say Hologram, and the way Bart has been involving everyone (/his meticulous attention to these kinds of details) has all the hallmarks of it potentially obtaining that all-elusive cult status :icon_cool: (This won’t just be good for Bart or Hologram, but for the entire Elixir community).


Back on topic, I don’t have any specific thoughts myself other than saying I hope whatever Bart decides echoes his goal of making Hologram as easy (natural and intuitive) and enjoyable to use as possible.

13 Likes

This is why I was drawn to Redux and Svelte Stores tbh. They allowed me to centralize state. So the components could be the method of composing UI, but the state could be centralized and decoupled which seemed a lot cleaner to me somehow.

Edit: Let me add an elaboration from an end user

Say you have some semi-complex state, and some of it is derived to either allow or disallow some action.

If the components are responsible for composing the data and deriving that, you have to pass the entire state to the component and then verify if the action is allowed, and then present accordingly.

OTOH, if the state can be decoupled, you can have the component be “dumb” which makes it easier to test in isolation. Then you have the state representation on it’s own which also makes it easier to test in isolation.

If the state is wrong, you have 1 place to check / debug. If the presentation is wrong, it’s dirt simple to sort out.

2 Likes

I think it depends on the overarching goal and vision for Hologram. Zooming out for a second, it seems like these design decisions are mainly influenced by these opposing forces:

  1. Offering complete control and explicitness
  2. Abstracting complexity and optimizing for ergonomics

#1 seems to generally lead to verbosity but you as the engineer have full control over how things work. #2 generally results in having to write less code but more trust in the framework. If we’re keeping in line with Hologram’s goal to make web dev simple, then I think it should lean more heavily into #2 even if it means sacrificing some sense of control.

With that said, I think composition can be achieved mostly with components. I like the way Hologram is currently designed in this regard. It feels Svelte-like which I prefer. I think the main area that wouldn’t fall directly inside of a component would be some sort of shared store. I typically reach for stores seldomly though, most of my composition is done with components.

Currently, for a store in Hologram, it looks like I’d use Context. If I wanted a global store, I suppose I’d have a Context at the app’s root (if I have this wrong, let me know). It might be nice to be decouple a store completely from a component and be able to use them in any component (maybe this is already possible?).

Beyond that, I think what is missing are:

  1. Derived / memoized values
  2. Side effects

I think it might be a nice DX if both of these were macros, maybe derived and effect (though I’ve never liked effect as a name, I’m not sure there’s a better alternative at this point).

Whatever you choose, I suggest keeping the api and macro surface area small. :slightly_smiling_face: IMO, Svelte has done well here whereas Vue has not for example.

To be fair, I’m a bit Svelte-brained at this point. I imagine others that are used to other frameworks will be biased in that framework’s way of thinking too.

One other thing worth considering is: will / should Hologram support fine-grained reactivity?

I agree with Derek though: Ultimately, Hologram should be a reflection of how you think it should work. All of the other frameworks succeeded based on the opinions and taste of the primary author. In Bart we trust. :slightly_smiling_face:

4 Likes

I share your view on composable state/store modules fully decoupled from UIs. Even with LiveView this is really powerful.

As an example, I have a few liveviews that are used by users but also used by programs.

Users act on state via LiveView’s handle_events, that call a public API exposed by the pure state modules to update the sockets, then LiveView re-renders.

But programs can build up state outside of components by creating and calling the pure state module’s public API in isolation, then just ask LiveView for a single render of the built up state.

There’s still coupling since those pure state modules represent UI state, not application state, ( UI_state = fn(app_state, user_or_robot_intents) if you wish) but being able to handle them inside or outside components is very valuable to me. That and the ability to compose smaller state into bigger state.

As Garrison showed it in the other thread, that makes for a bit verbose code for the simpler cases.

I also think Bart is leading the community in a new direction with Hologram and has all the rights of trying a few things and changing his mind :slight_smile: at least before 1.0.0 ! (And even after)

3 Likes

Just to clarify, my concern is mainly with complex (real-world) cases; simpler cases tend to come up only in examples. Whether you agree with me is another matter (and I won’t drag that debate here), but that’s my intent.

1 Like

While I do make the final decisions based on what feels right, I’ve learned that designing in isolation would likely create a project perfect for some past version of me, but not necessarily for the broader community. Hologram has grown beyond just my personal project - there’s already a growing number of projects using it, including in production. The broader success of Hologram means more Elixir use cases and potential new jobs for the ecosystem.

I hear you both on this. The challenge is that after 5+ years, nearly 10k commits and 1M lines of code, the project has real inertia. Changing core APIs at this stage isn’t a quick iteration - it’s measured in months of work, especially with plans for component libraries and other tooling that depend on these decisions. I don’t have infinite time to experiment, which is exactly why I’m being deliberate about these crucial architectural choices now.


To be clear, I’m not trying to please everyone - I’m trying to understand the solution space and how different patterns might serve real use cases. The feedback here helps with that, even if the final direction is my call.

8 Likes

Great point about the reducer pattern - Hologram actions already work this way (current state → action → new state), so this validates that approach. I’d also love to explore how Svelte stores would translate to Hologram, and how these concepts could enable composability patterns. Would you be interested in showing a simple code example of how you’d imagine this in Hologram?

Wow, thank you! :blush: I’ll admit I overthink things constantly (just ask anyone who knows me), but at least it’s paying off in ways that matter. The cult status thing made me laugh though - let’s see if we can earn it!

3 Likes

Great insight, @jam! I completely agree with your framing of these opposing forces.

What’s interesting is that this tension probably maps quite directly to the macro question: #1 (complete control and explicitness) likely means minimal or no macros, while #2 (abstracting complexity) would lean heavily on macros.

This puts me in a tricky position. The Elixir community has historically been quite reluctant about macro-heavy APIs, and for good reason - explicitness is one of the core values that attracts people to Elixir in the first place. You can see this playing out with Ash Framework right now. It’s extremely macro-heavy, which lets it elegantly solve complex problems and reduce boilerplate dramatically. But that same characteristic creates polarized opinions: some developers swear by it because of the power and conciseness, while others can’t get past all those macros because they value explicitness and direct control.

If I go the macro route with Hologram, I’d likely deter a significant portion of Elixir developers who prioritize that explicitness. On the other hand, macros could eliminate a lot of the plumbing code and enable powerful compile-time analysis (which Hologram is uniquely positioned to leverage with its full call graph visibility).

The challenge is that Hologram’s North Star is developer experience (DX), but that means different things to different people in this context - and that’s exactly the problem. For some developers, great DX means explicitness and control: no magic, always clear what’s happening under the hood. For others, great DX means less boilerplate and cognitive load: abstractions that “just work” and let you focus on your application logic. Both are valid perspectives on what makes development enjoyable and productive.

So I can’t simply say “optimize for DX” - I need to decide which developer experience I’m optimizing for, knowing that choice will resonate strongly with some developers while alienating others.

The question is: does it even make sense to look for middle ground here? Or would that middle ground end up being the worst of both worlds - not explicit enough for the control-oriented developers, yet not ergonomic enough for those seeking simplicity? You’d potentially end up with something that doesn’t fully satisfy either group.

That said, there are counter-examples. Phoenix’s routing DSL and Plug’s pipeline builder are heavily macro-based, yet they’ve been widely accepted by the Elixir community. Maybe the key is whether the abstraction feels “worth it” - whether what you gain justifies the magic you’re accepting.

2 Likes

Just to clarify - Context isn’t really meant to be a store. It’s for avoiding prop drilling by letting components emit data that flows down to their children (who access it via props with from_context).

You could use Context at a page level as a “global store” and mutate it from anywhere by specifying the action target, but it would feel awkward/indirect. Context is component-bound, like React’s Context API. It’s not a decoupled store like Redux or Svelte stores.

I think what you’re describing - a truly decoupled store - is what @nikfp mentioned earlier too. I’d love to see what that would look like translated to Hologram if you have ideas!

1 Like

I’d like to take a stab at what the usage would look like on this, if at least to inform my opinions better. Let me cook a while and I’ll reply again with what I come up with.

3 Likes

This sounds interesting, would you mind sharing a simplified example of how you structure and compose these state modules?

Yep, I agree. It’s funny too because I had the same two examples in mind (Ash and Plug / Router). IMO, it’s possible to keep macros to a minimum where they truly impact ergonomics for the better and offer some unique capabilities. I’d imagine there’s probably something on the order of a handful of macros max that would fall in that category.

1 Like

Indeed, but it’s also the cost of getting things right. To again use React as an example, they essentially redesigned the entire thing (backend and frontend) with fiber/hooks after about 5 years. Post-hooks React may as well have been a new framework. Honestly, the fact that they got away with pretending it wasn’t a new framework is kinda hilarious. They did go out of their way to maintain backwards compatibility and interop, which is impressive. Presumably that was a business requirement.

I stand by what I said: you can either spend years on this stuff or copy the things that already work, recognizing that those things have been through years of evolution already and that is, in fact, why they work. Personally I choose to do a lot of copying because I don’t have infinite resources, but if you want to greenfield stuff I have nothing but respect for that. It just takes a while!

WRT the macro discussion, I don’t really have anything against macros. I do like the expressive power of a real programming language, but I think that’s actually orthogonal. My concern, which I have probably already expressed enough, is that the direction you’re proposing is equivalent to creating a new programming language in Hologram. It may not seem like it now, but I think it would end up that way. So the question becomes: is your programming language going to be good? And if you haven’t even accepted that you are rolling your own programming language, the answer is almost certainly going to be “no”. This is the curse of DSLs.

One more thing: Hologram’s raison d’etre as I understand it is to be “Elixir on the client”. If you lean too heavily into a DSL, even if that DSL is good you are working against that mission. That could be a branding problem.

2 Likes

Can you explain in more detail what you mean with the call graph stuff? Is the call graph static? What happens if I try to make a function call dynamically?

I fear it isn’t, my work is deep in the depths of what I call officetech or boringtech :grinning_face_with_smiling_eyes: .

Most of my work involves tools that produce book-like or slides-like material, with a data structure that is tree-like, but their physical projection is a flat list of pages in the end. Or a list / tree of such documents, but a single document ends up a flat list. Backend state is nice to interact with programmatically and frontend state is nice to interact with from an user’s point of view. Both are linked but very different. Users acting on the tree model would be an horrible UX and interacting with the flat model programmatically would be horrible DX.

So it simply is deeply nested structures of very simple Elixir structs + their management functions. The UI is a function of the tree structure by the frontend framework (Vue* in my case - a bit of a regret). The frontend sends events to the backend through websockets, applies optimistic updates, then applies partial or full updates from the backend’s answers, to the projected state.

Re : composition, I liked the spreadsheet-like example I shared in the other thread because of an explicit composition operation where a sub-graph’s outputs could become a wider graph’s inputs. I will see if that stands the test of time and resists to feeding a bigger UI.

To summarize it, I am posting in those threads because I am looking for ideas about interesting state managment and transition patterns, fully isolated from the UI.

Sorry, it’s a bit confused, because I am actively thinking about different re-structures and a bit “in the depths” of it these days.

(*Well Vue or Liveview depending on acceptable latency)

1 Like