codeintellify icon indicating copy to clipboard operation
codeintellify copied to clipboard

Implement modular architecture

Open ijsnow opened this issue 6 years ago • 0 comments

The hoverifier code needs to be broken apart. Two of the main reasons for this are as follows:

  • Each piece will be easier to test on its own
  • The pieces that need to be configured in order to make this code shareable are currently buried in the middle of what I think of as being the state management layer.

Architecture overview

State management: Basically hoverify but without the finding position logic and highlighting. Ideally, we could pipe in a PositonEvent { postion: Position, eventType: 'click' | 'hover' } and it would emit a HoverState. Rendering HoverOverlay: Takes the output from state management as a prop and renders the HoverOverlay component as it is now as well as highlights the range from hoverOrErrorOrLoading since Hover has a range. Position calculations: Calculating the positions of mouse events on the code elements.

Breaking it up like this has some benefits when you get to reusing it on n code hosts. I think the biggest benefit is that these are the three main pieces of this and they should be kept close to the main entry point we were talking about earlier so that we don't have to pass configuration options for different code hosts and their different types of views around.

Main entry point

There is still going to be a main entry point for use in the code hosts. We'll need to discuss what we want this to look like. I'm open to pretty much anything once we get the above architecture worked out. The most important thing for sharing in my opinion is keeping the positioning logic close to the entry point.

Notes about supporting code hosts

State management should change 0% for any of the code hosts. Rendering HoverOverlay should not really change either other than where its rendered. Highlighting the active token this could be done in the overlay or elsewhere but I don't think the current implementation is the way to go because it still requires manipulating and traversing the dom. Position calculations should change just a little with each code host. This will eventually be encapsulated by dom-positions.

Steps to get there

  • [ ] Remove all references to HTMLElement from hoverifier
    • [ ] Make hoverifier accept an observable of positions from mouse events instead of accepting multiple observables of mouse events
    • [ ] Don't require a dom element to be found for location changes
    • [ ] Handle scrolling to token if needed outside of state management
    • [ ] Highlight token outside of state management
    • [ ] Highlight lines outside of state managment ... more

ijsnow avatar Jun 30 '18 03:06 ijsnow