gistfile1.txt

pointfree.co question: 'ListAction'?

I have been working on an app that has a very complex GUI.  Think of a digital synth plugin where there are many levels of
nesting components (faders in envelope banks in presets of a project, etc.). One pattern I observed was that at each level 
in the hierarchy I have to operate over some generic ‘element’ as well as manipulate the elements as a group.  For this I
defined a ‘ListAction’.  It looks roughly like the following:

enum ListAction<Element, ElementAction, ID> {

    // … “List level actions”
    case select(ID)
    case reorder(e1: ID, e2: ID)
    case deselectAll
    case insert(Element)

    // … “Element level actions”
    case update(at: ID, action: ElementAction)
    case updateSelected(action: ElementAction)

   // experimental: “List and Element actions?”
    case applyActionWhenAllSatisfied(Predicate, ElementAction)
}

The purpose is to enable ‘ForEach’ like functionality, e.g. as in ForEachStore.  My concern is that reducer.forEach
doesn’t go far enough.  There is a myriad of ‘set level’ logic that is repeated.  (especially in my overly-complex nested
GUI, haha).  This logic appears to be general enough to apply to most modern apps.  Things like “apply operation X to all
selected elements”,  “apply operation Y to elements meeting an arbitrary predicate”.  Do you have any ideas for how TCA 
would represent these ideas?  Should they be baked into the action (which would go along with its own higher order 
reducer, store, and view store?  Or should the list logic be implemented as some type of ‘Entities domain’ that gets
somehow ‘merged’ / composed over the element level domain?