Ref: elmish/elmish PR #248.
An early prototype of the "live subs" demo used the subscription settings + Msg type as the subscription ID. This worked as long as you only needed a single subscription. But it did not allow, for example, two timers on the same page with the same settings. That led me to switch to a user-provided Sub ID. This gives the user full control on when subscriptions are different or the same. It also gave ID the responsibility of triggering changes to a running subscription.
Subscriptions only have start/stop semantics. So "change" means stopping the running one and starting a new one with different settings. How ID controls this is illustrated in the live subs demo. Notice under Subscriptions -- which lists subscription IDs -- that the timer interval is part of the ID. When the user changes the interval from 1000 to 2000, the subscription ID goes from ".../interval/1000" to ".../interval/2000". This causes the old 1000ms subscription (JS interval) to stop and a new 2000ms sub to start. Conceptually there is only 1 app clock timer. But different settings makes it a different subscription instance.
When I switched to a fully user-provided Sub ID, it could be argued that too much responsibility was shifted to the Sub ID (and therefore the user). Like above, a change in subscription settings will usually mean the subscription is different. So the user will have to incorporate the same data into Sub IDs that they provide as subscription settings. It feels like duplicate work.
graph TD
subgraph Timer Subscription
SubId[Subscription ID]
SubData[Subscription Settings]
Model -- local ID --> SubId
Model -- interval --> SubData
SubData -- interval --> SubId
end
I think @et1975 was trying to tell me this when we chatted. Per his suggestion, we could allow the user to choose the degree of responsibility. For example: an ID of Auto could have the subscription's ID depend only on the subscription settings. That would have worked for the demo clock. On the other end of the spectrum Custom could be fully user controlled (subscription settings ignored for ID purposes). There's room in between for the combination of a local ID + subscription settings, so the user can differentiate two subscriptions locally, like "timer1" and "timer2", but they will automatically restart when the settings change. Probably the easiest way to do this would be to have the sub provider stringify the subscription settings (maybe provide some helpers), which would get combined with the local ID. This all assumes assumes that IDs are scoped/prefixed to their owner, which idPrefix is doing for us when mapping.
Thoughts?