Signals, computed properties and other reactivity patterns in Hologram

An example of signals based framework is Datastar. In Datastar if I do

<input type=”text” data-bind=”name”/>

A signal name would get created. Typing in the input would update the value of name. Updating the value of name from outside would change the value of input element.

More on this here - Reactive Signals Guide

Interesting, not to go too far off track here but I found solid.js reactivity-model to be very intuitive and appealing at a first glance. @LostKobrakai probably has lots of knowledge here:)
How relevant is this to hologram in terms of databinding and other client side aspects, could something like it be used?

Signals are compelling, but they’re fundamentally a JavaScript reactivity primitive. Hologram transpiles Elixir to JS, preserving Elixir’s functional semantics - immutable data structures, explicit state updates via put_state, etc. Adopting signals would mean either reimplementing them in Elixir semantics (complex) or breaking from Elixir patterns (defeats the purpose). The current explicit approach aligns better with Elixir’s philosophy.

That said, a middle ground with similar purpose is planned - computed values/properties. This would give you automatic recalculation of derived state when dependencies change, similar to Vue’s computed properties, while maintaining the explicit, declarative, functional style that fits naturally with Elixir.

I would only suggest that you be wary of half-measures. If you will recall I also once suggested adding computed assigns to LiveView, but having since educated myself further I now realize that this approach does not go nearly far enough.

What is interesting about post-hooks React is that they finally came up with a way to structure entire components declaratively. Even pre-hooks React did not live up to this goal, just as LiveView fails to live up to it today.

The difference between a signals approach and React’s approach is, philosophically, somewhat similar to the template debate. They are both declarative, but I think that signals take power away from the programmer rather than grant it. The difference here is much more subtle and involved than the template case, though.

Computed properties are, in isolation, the same thing as signals. You are forced to model each little piece of the code in terms of how it responds to changes in other parts. There is no forest; you are only concerned with the trees.

React’s model is much more interesting: you write the components declaratively as a whole. You are concerned with how a component responds to changes in its state, not each individual fragment. This matters because the code within a component is meant to be deeply interconnected and and cannot and should not be pulled apart.

I worry the “just add computed properties” approach will fundamentally lead to an imperative style with little bits of declarative code thrown in there at random, which is no solution at all.

At least signals frameworks commit to using them for everything, even if I think that solution is ugly and inexpressive.

When I said “middle ground” I didn’t mean “half-measure” - that was unfortunate wording on my part. I’m talking about reaching similar goals - automatic recalculation, performance optimization - but in a way that aligns with functional programming principles. I think computed properties actually fit naturally into the functional paradigm: they’re pure functions that transform immutable state into derived values. That’s fundamentally functional.

I know you’re not a fan of templates, but computed properties actually strengthen the template-as-presentation-layer approach by letting you move business logic out of templates into small, focused, testable functions.

To be clear: when I talk about computed/derived properties, I mean values like full_name, valid?, or formatted_price that derive from existing state - not template fragments. (Partials like <my_partial(param_1, @param2) /> would be a separate feature for generating template fragments.) These are tools in your toolbelt, not fundamental architectural commitments.

I think it’s worth considering the concrete benefits they provide - they solve real problems:

• Performance: Automatic memoization of expensive calculations
• Consistency: Derived state that can’t get out of sync when multiple values depend on each other
• Readability: Clear separation between data and derived values
• Testability: Small, pure functions that can be tested in isolation

Regarding “there is no forest; you are only concerned with the trees” - I understand your concern about losing the holistic view. But I think the key difference is that computed properties in Hologram would be values derived from state, not a reactive programming model that forces you to think in terms of dependencies and updates. You still write your component declaratively as a whole - the state updates explicitly through actions, and computed properties are just transformations of that state. The component’s logic remains interconnected and whole. Computed properties are simply a way to extract and name derived values rather than calculating them inline in the template.

Additionally, when components are small and properly isolated with focused responsibilities, it becomes easier to keep the entire component in your head at once - the “trees” are manageable and the “forest” emerges from how components compose together.

The key point: computed properties in Hologram would be optional and complementary to the existing explicit approach, not a replacement. They’re a tool for specific use cases where the benefits are clear. I want to be pragmatic about giving developers useful tools while maintaining a coherent architecture.

Hi @bartblast !

I agree with @garrison

The React (and Elm) paradigm of ui = fn(state) IMHO fits most naturally with a functional paradigm and is easier to reason about. Efficiently keeping the ui in sync with the state is an implementation detail.

I have not tried the more recent frontend frameworks that use Signals, but I did use KnockoutJS and EmberJS many years ago which used computed properties–something similar to signals. I found them harder to reason about because you have all these values with interdependencies scattered everywhere. It becomes much more convoluted.

I would raise the question: what is the benefit of having computed computed properties over a ui = fn(state) functional paradigm?

IMO, computed properties are really nice and I use them liberally in svelte with $derived. It’s nice to keep logic out of the template, assign it to a variable and insert that variable in the template {@something}. I think they also memoize automatically.

Hi @venkatd, thanks for the feedback!

I completely understand your wariness based on KnockoutJS/EmberJS - those frameworks created convoluted webs of interdependent computations that were hard to trace.

However, I think those issues stemmed from their mutation-based reactive model: mutable observables, dependency graphs spanning multiple files/components, scattered observers with side effects, and hard to trace execution flow when changes cascade through dependencies.

Hologram’s approach is fundamentally different:

• Immutable state with explicit updates
• Dependency graphs scoped to component state and props only - local and bounded
• Pure functions, no scattered side effects
• Clear data flow: action → state update → re-render

Yes, there would be a dependency graph for computed properties, but it’s deterministic, local to the component, and traceable by reading the code. No hidden global reactivity. This explicit nature would even enable a Time Travel Debugger to track all actions, commands, and the computed properties graph in real-time.

Computed properties would be named, memoized pure functions that transform state. They’re still part of ui = fn(state) - the function is just composed of smaller, named, cached transformations.

Why memoization matters in ui = fn(state):

The key is that some form of memoization is needed anyway. Without it, you face: repeated function calls with identical inputs, expensive recalculations on every render, composed calculations where all functions in the chain recalculate even when inputs haven’t changed. Your options are: recalculate everything (expensive), manually cache (boilerplate), or automatic memoization. Computed properties provide the latter while keeping the functional paradigm intact, plus they help move business logic out of templates into named, testable functions.

Computed properties would be completely optional - just a tool in your toolbelt for cases where they provide clear value.

Does this address your concern? I know the term “computed properties” carries baggage from various JS frameworks, but I think the fundamental paradigm difference (immutable, functional, local) makes them a different beast entirely. Would love to hear your thoughts on solving these memoization challenges, or if different terminology would help clarify the distinction.

I haven’t replied again out of concern for this specifically. I want to make sure I’ve seen the API you have in mind before I give further thoughts. Plus it will probably be easier to explain what I have in mind if I can demonstrate it in terms of what you already have.

BTW, your dedication to responding to feedback on here is amazing. Don’t think it goes unnoticed!

Hi @bartblast thanks for the clarification

Perhaps because the term “computed properties” means many things to many people which is what is causing the confusion.

If I understand right, you are still following the ui = fn(state) pattern. Computed properties really means memoizing functions so re-renders are efficient? If that is correct I feel a lot better about computed properties.

And btw I think memoization might be a clearer mental terminology for what is going on here.

As @garrison said I think some pseudocode would give us a good idea of what you mean