You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 25, 2021. It is now read-only.
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
The hoverifier code needs to be broken apart. Two of the main reasons for this are as follows:
Architecture overview
State management: Basically
hoverifybut without the finding position logic and highlighting. Ideally, we could pipe in aPositonEvent { postion: Position, eventType: 'click' | 'hover' }and it would emit aHoverState.Rendering
HoverOverlay: Takes the output from state management as a prop and renders theHoverOverlaycomponent as it is now as well as highlights the range fromhoverOrErrorOrLoadingsinceHoverhas 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
ncode 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
HoverOverlayshould 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
... more