Discussion around TreeWalker internal representation of the jurisdiction tree

[peterMuriuki]

I think in the interest of standardization, which would help keep the Tree walker maintenable and less bug prone, the tree walker should provide unified api interface to the wrapped component.

an Instance of an end-goal, would be:

• a dev can modify the computation of current Children when the parent node changes, only in a single place, currently you have to consider when the tree-walker is using the
  plan hierarchy endpoint and when its building the hierarchy itself by making service calls to using the location endpoints
• another nice to have requirement would be for the jurisdictions to conform to a single non-intersected type.

[peterMuriuki]

I believe a tree ADT is a very natural selection to model the type of data that the TreeWalker component is dealing with.

The component Itself needs to support loading on-demand jurisdictions using the ancestry helper functions. This is when not using a hierarchy from opensrp. It still needs to support being able to provision the hierarchy during times when that is feasible. It should ofcourse hider the representational information from the wrapped component.

The wrapped component need implement different ways of handling the node objects. This is just a matter of unifying the ParsedHierarchyNode and OpenSRPJurisdiction. Creating an intersection of the two that guarantees common key properties are exposed from the same prop names and at the same nested level in a jurisdition object; while properties that are not in both are exposed as optional property names.

wrapped components need not have to deal with different jurisdiction types.

Question should the the tree walker use reducer or just good old-fashioned react context?

One other question is that if the Tree walker component can be extended with functionality like selecting nodes.