Add ability to easily extend Locust web UI

[solowalker27]

Is your feature request related to a problem? Please describe.

It would be very nice to be able to extend the Locust web UI to make custom data visible natively in the same UI as the basic Locust stats. A separate route for each data set I want to view that's just a dict/JSON or some other generic raw data view that I have to manually refresh is a very poor experience. They're also completely undiscoverable to other people who may be using my Locust set up to run tests. Being able to extend the UI would solve all these problems and open up a lot of other interesting possibilities.

Describe the solution you'd like

We already can add new routes to Flask relatively easily. And data can be passed from workers to the master so the master can do things with data from the workers, including serve it via added routes, and I have done so. What's missing is a UI component.

This would first require adding some extension blocks to index.html. That would allow users to create their own HTML file that extends 'index.html'. That's the easy part. I've attached an example of this that I'm currently using.
index.html.txt

The problems come from actually trying to go any further. I was ultimately able to accomplish the end result of serving up an extended UI page but ran into several issues that made it more difficult than I think it could be. To make this a viable feature, I feel like the following would need to be addressed:

1. Before I can serve additional files such as my extended HTML page or a Javascript file to go with it, I have to create my own jinja instance to look for the path I want to store my files in. There may be an easier way to do this, but this is what I found to make it work:

        templateLoader = jinja2.FileSystemLoader(searchpath="./")
        templateEnv = jinja2.Environment(loader=templateLoader)
        template_file = "file.html"
        template = templateEnv.get_template(template_file)
        …
        template.render(
            # all the stuff index.html needs
        )

2. I had to copy almost all the code for the / route in web.py to make sure I got everything the index.html page needs to render my extended page properly because of the number of variables index.html relies on.
3. Since there's only a single CSS style sheet allowed per page, I do have to do my styling in Javascript.

If there's no better way to do number 1, it'd have to be accepted and just included as part of the documentation.

For number 2, I'm thinking there may be two ways to do it. Either make everything index.html needs be somehow accessible in a single dict (maybe be included in the init event kwargs), or go the other way and somehow allow / to serve my extended html page instead so it is still passed in the args in a single place. This might even be preferable since / would go to my extended page instead of having to redirect it elsewhere or just use the other route directly. Depending on the implementation, tackling this might also solve number 1. As it currently stands, I'm not sure how this would work, though, since the init event relies on the web server already being started in order to pass it along so we can do things like add routes. Perhaps separating Locust init and web init so the web stuff can be overwritten/extended first, then routes can be added later?

For 3, I'm not aware of a way to extended CSS so this may also need to just be accepted and documented. Only other thing I can think of might require a good sized effort to somehow rewrite the HTML and Javascript elements to be reusable and named in some generic fashion for the CSS to target all tables and charts, for example.

Describe alternatives you've considered

As implied in the previous section, I've already worked around the current limitations with a bunch of extra work, forking index.html and copying code from / route to another route to serve my extended page and dealing with the other issues.

I've also considered using just the straight data-only routes as mentioned in the first section but quickly dismissed that as largely untenable.

[cyberw]

I have literally no clue about this UI stuff :)

But I’m in general positive to making the UI more customizable, particularly if it can be done without major changes.

[cyberw]

Marking this as low prio (not that I dont want it fixed, but I wont have time to do it myself)