centralize frontend implementation for session history

[tmack8001]

getting tired of copy/paste into 5 different session_type files that are essentially exactly the same (minus a few slight variations). For each session type we have the following copy/pasted frontend files:

• {session_type}_history.js
• {session_type}_history.html

The below files are also very similar... and is massively annoying to me when changing the layer or optimizing the view to have to remember to copy/paste into a number of them so I'm looking to ways to consolidate those as well:

• {session_type}_graph.js
• {session_type}_graph_socketio.js

[chiefwigms]

Worked well when it was just brew history 😃

[tmack8001]

I'll take another stab at completing this... though now I've changed a bunch of brew specific stuff 🤣

[tmack8001]

Decided to while I was messing with history view to also support a VERY large sized history... the rendered HTML of 100+ sessions takes many many 10s of seconds to return to a client device increasing the TTI (Time To Interaction). However if we infinitely paginate 10 at a time client side the initial TTI is within a second most of the time (depending on session sizes, fermentation data is LARGE depending on config for polling) all other historical sessions can be scrolled to and loaded with AJAX not impacting the TTI of the site.

View the experience below from my dev machine, from a networked Pi the history experience and TTI is so much better:

[tmack8001]

TTI example of the new experience:

going back to the master build... to show the difference this pagination makes... pay close (not really!) attention to Content Download length of the /brew_session request.

Now the above are from my dev machine (fake sessions, and most session files are blank of data).

Check out my Pi setup that has all my sessions from the past 1.5 yr.

[tmack8001]

top load is from this branch bottom load is from master branch

page size drastically different due to less sessions loaded into the rendered HTML