Refactoring Backlog

[paulftw]

Implement proper Redux in FrameItem

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

Overall this problem slows down development

[paulftw]

FrameSession is immediate child of FrameItem and does redux-style state management ops, FrameItem does fetching of queries but stores everything in the state.

[paulftw]

Approximate steps to fix:

1. make FrameItem connected
2. Move Frameitem state into redux store
3. make FrameSession presentational - disconnect FrameSession and move its dispatchers into FrameItem
4. maybe find entirely new home for FrameItem logic
5. ???
6. Profit!

[paulftw]

Extra task:

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.

[paulftw]

Extra ^ 2:

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.