Re:Making Elm faster and friendlier in 0.16
by tlarkworthy on Thursday November 19, 2015 @04:19PM
(#10597766)
No because you must might want a whole subgraph of dataflow associated with each instance. You are right you can perhaps do it with collection primitives as signals. Creating tables is appropriate for multi tenancy apps. Or apps that let you build apps, or analogously, a drawing program for graphics.
Re:Making Elm faster and friendlier in 0.16
by skybrian on Thursday November 19, 2015 @04:31PM
(#10597851)
So, an app builder will need to simulate signals in a purely functional way, rather than using the top-level, native signals. But if you want to write a debugger for the child apps, you need something like an interpreter anyway.
At the top level you might just have a single native signal for all events delivered to any child app.
But I agree that the ability to start and stop reactive sub-programs would be a useful thing.
All instances of the same message type can share a signal, as long as the messages contain a unique key to distinguish between objects, and the code that lives downstream filters events by key.
It's much like a database-backed app where you don't dynamically create tables while your app is running. Instead, instances are stored within a table and identified by their keys.