@bartblast after giving the stores API some thought, here’s where I landed. Keep in mind that this is naive and based on the public API in the Hologram docs. I’ve made some assumptions as well that I’ll do my best to outline as I go.
Commentary from anyone who’s interested is also welcome, even it it’s just to say “this is a terrible idea and the reasons are XYZ 
“
I would see the core of the stores starting with a struct looking roughly like this:
%Store{
id: "some-name",
root_component_cid: "component-name",
implementation_module: MyApp.CounterStore
state: %{
value: 0
}
}
State could be as simple as a single value, or nested structures to allow for complex requirements.
Stores could be built up from a core implementation to allow for customization like so:
defmodule MyApp.CounterStore do
use Hologram.Store
# callbacks
@impl true
def init(initial_value) when is_integer(initial_value) do
# Any processing needed to prepare the initial value passed in
initial_value
end
@impl true
handle_update(:increment, state) do
%{value: value} = state
updated_value = value + 1
%{state | value: updated_value}
end
@impl true
handle_update(:decrement, state) do
%{value: value} = state
updated_value = value - 1
%{state | value: updated_value}
end
end
This makes the assumption that there is an engine for storing stores, locating them as needed for updates and change tracking, and getting that to work in JS is built first.
Creating stores would take place in an init function of a stateful component, and the store itself would be treated like state. A utility function would build it, another function would allow binding to a value, and the store itself could be passed as a prop. I would assume that somewhere in here (that I haven’t listed) the cid of the root component would need to be attached to the %Store{} struct.
defmodule MyApp.Counter do
use Hologram.Component
alias Hologram.Store
def init(_props, component) do
# returns a %Store{} struct, wired up as needed
counter_store = Store.build(MyApp.CounterStore, 0)
put_state(component, :counter, counter_store)
end
# bind the UI to the :value key in the store, or a nested value if appropriate
# pass the store as a prop to ancestors
def template do
~HOLO"""
<div>
<p>{Store.value(@counter, :value)}</p>
<MyApp.CounterButtons counter_store={@counter} cid="buttons" />
</div>
"""
end
end
Another utility function would allow for updates, and would know which module to dispatch the function to, based on the module name in the struct.
defmodule MyApp.CounterButtons do
use Hologram.Component
alias Hologram.Store
prop :counter_store, :store
def template do
~HOLO"""
<button type="button" $click={action: :increment, target: @cid}>increment</button>
<button type="button" $click={action: :decrement, target: @cid}>decrement</button>
"""
end
def action(:increment, _params, component) do
# The update function would delegate to the implementation of the store
# store update functions could rely on pattern matching,
# though I'm not sure how well this would work when translated to JS.
store = Store.update(component.state.counter_store, :increment)
put_state(component, :counter_store, store)
end
def action(:decrement, _params, component) do
store = Store.update(component.state.counter_store, :decrement)
put_state(component, :counter_store, store)
end
end
A derived store would then follow a similar pattern, but only have an init function callback. Said function would take the a base store and a function to run to calculate the derivation each time the state of the base store changed. In a perfect world, the base store could be another derived store, allowing chaining derivations for more complex calculations. Similarly, allowing the base store to also be a list of several stores would allow deriving from several sources reactively.
Stores could then be “passed around” as needed, even through a context, and changing them through an explicit call in one place would trigger the reactivity chain for the store throughout rendered components. This would also decouple stores from the component state which would make them testable in isolation.
Let me know if I’m anywhere near the ballpark of what you had in mind.
- we agree on the facts (hooks use hidden mutable state), but you’re reframing it as a necessary emulation of a functional pattern rather than a design issue. I see the argument, though I’m not entirely convinced that “abusing global state to emulate a functional construct” is necessarily more functional than having explicit state management. But I’m open to being wrong here.