Currently GraphContainer is a container, FrameItem is not.
However, FrameItem is doing query execution and processing, storing it all in internal state (not redux).
Apart from violating ‘pure redux’ conventions this introduces several problems:
child components depend on parent to do logic for them
changing behaviour is not obvious: FrameItem has to be updated to add any new feature
it’s hard to find where certain logic is - it’s not always in reducers and fetch results are not in store
FrameSession is immediate child of FrameItem and does redux-style state management ops, FrameItem does fetching of queries but stores everything in the state.
In FrameLayout.js there’s changeCollapseState function. It dispatches an action, but also emits callbacks.
It has a logic block: if I’m dispatching “collapse frame” - do collapse callback. If I’m dispatching “expand frame” - do a callback that will fetch a query.
There are multiple anti patterns in this code:
doing logic in dispatcher,
frame fetching being imperative not declarative,
FrameItem is stateful and that state is managed by external, often child, components.
fix: make FrameItem self contained and reactive to prop changes. it must be a state machine controlled by changing props or redux store.
FrameItem is single component for query frames, mutation frames, alter frames. and error messages.
With inheritance pattern it can be broken down into multiple simpler independent components.