Add reduction history page to display runs

[Dagonite]

Closes #33.

Can now view runs via the reduction history page.

How to test

Get a populated database connected to the API. Run the API with uvicorn ir_api.ir_api:app --host 0.0.0.0 --port 8080 on the implement_specification_pattern branch. Launch the plugin and see if ir/reduction-history/{instrument} is populated with runs for each instrument.

Build the frontend repo and test when ran through SciGateway.

[Pasarus]

Ok so I made a quick change to solve the issue that we are presently unable to define where the API URL. This can now be set in a new .env file, with a default here using localhost:8000 as per the code submitted.

Locally I am using prod as the requests here should not impact the contents of the data.

For the actual issues with this web page:

• You cannot sort by RBNumber, Run Start time, Run End time or Run Output. This returns us wildly not useful data on the front page and we should default to sorting by RBNumber or probably Reduction ID in an extra column as that was added to the DB most recently? as that will be the most useful information for a user to see. Every column should be sortable on this page.
• I am not convinced the Run Output is correct. It's missing more than one file in any scenario? it seems to be the run input file. Come to think of it should be a separate column just after RB Number, these 2 columns can be quite thin.
• Would it be possible to follow this: https://stackoverflow.com/a/66817589 it would be great to alternate colours on the table to ensure that a user can easily follow data along and improve readability.
• The page takes a very long time to inform the user it is doing anything when switching from one instrument to another. It just takes a long time to do anything with the IR-API so I'll have a chat with Keiran tomorrow to see what he thinks might be the issue.

[Dagonite]

You cannot sort by RBNumber, Run Start time, Run End time or Run Output

Is it even possible to sort by these with the way the API is? From my understanding and implementation right now, one fetch request needs to be made just to return a single run. So sorting would have to be done on the frontend because the API doesn't offer this functionality.

I am not convinced the Run Output is correct. It's missing more than one file in any scenario?

I can only see one "Run Output" file per run. I don't think the db_generator script generates runs with multiple of these files unless I'm mistaken?

Would it be possible to follow this: https://stackoverflow.com/a/66817589 it would be great to alternate colours on the table to ensure that a user can easily follow data along and improve readability.

Will do 👍

The page takes a very long time to inform the user it is doing anything when switching from one instrument to another. It just takes a long time to do anything with the IR-API so I'll have a chat with Keiran tomorrow to see what he thinks might be the issue.

Is relatively quick on my end but it might be because of my hardware. But yeah the short delay is the API fetching 50 (think is the default I set it to) reductions, then counting how many reductions the specific instrument has to determine pagination, and then getting runs for those 50 reductions using their IDs. So it's doing 52 fetch requests per page because I see no other way to do it.

[Pasarus]

Is it even possible to sort by these with the way the API is? From my understanding and implementation right now, one fetch request fetch needs to be made just to return a single run. So sorting would have to be done on the frontend because the API doesn't offer this functionality.

If you need increased functionality to provide these frontend features that can be requested, please do so if you require it either by going through @keiranjprice101 or me.

I can only see one "Run Output" file per run. I don't think the db_generator script generates runs with multiple of these files unless I'm mistaken?

You are mistaken, I am using real-world data to test this.

The page takes a very long time to inform the user it is doing anything when switching from one instrument to another. It just takes a long time to do anything with the IR-API so I'll have a chat with Keiran tomorrow to see what he thinks might be the issue.

Is relatively quick on my end but it might be because of my hardware. But yeah the short delay is the API fetching 50 (think is the default I set it to) reductions, then counting how many reductions the specific instrument has to determine pagination, and then getting runs for those 50 reductions using their IDs. So it's doing 52 fetch requests per page because I see no other way to do it.

The reason why it is fast for you and not for me, is that you are pinging your local API with your local DB, I am pinging the actual in production API, with the actual in production Database with real world data.

[Dagonite]

If you need increased functionality to provide these frontend features that can be requested, please do so if you require it either by going through @keiranjprice101 or me.

Then yes I would need this functionality otherwise all the runs would need to be fetched first before any sorting could occur.

The reason why it is fast for you and not for me, is that you are pinging your local API with your local DB, I am pinging the actual in production API, with the actual in production Database with real world data.

Could we get this set-up for me so I can be using more accurate reduction data?

[Pasarus]

Then yes I would need this functionality otherwise all the runs would need to be fetched first before any sorting could occur.

Can you detail the calls you want to make? and the expected output

Could we get this set-up for me so I can be using more accurate reduction data?

I've messaged you on teams.

[Dagonite]

Can you detail the calls you want to make? and the expected output

Something like these with sorting query strings?

---

1. /instrument/{instrument}/runs

E.g:

[
  {
    "filename": "/archive/NDXHIFI/Instrument/data/cycle_19_02/HIFI64374.nxs",
    "experiment_number": 64374,
    "title": "Remember professional outside young both environment discover hope official.",
    "users": "Connie Brown, George Ruiz",
    "run_start": "2021-03-08T07:41:16",
    "run_end": "2021-03-08T08:13:16",
    "good_frames": 7795,
    "raw_frames": 9514,
    "instrument_name": "HIFI"
  }
]

---

2. /instrument/runs same as above but returns all runs and isn't instrument specific

---

3. /instrument/{instrument}/runs/count

E.g:

{
  "count": 300
}

---

4. /instrument/runs/count

E.g:

{
  "count": 10000
}

[keiranjprice101]

@Dagonite
So I will add the following. Let me know if this is complete

/runs returns all runs across all instruments, with limits offsets and order_bys like reductions
/runs/count same as above but count only
/instrument/<instrument>/runs runs for instrument

[Dagonite]

@keiranjprice101

Yes, looks right.

[Dagonite]

When testing this PR I assume you won't be able to do it using the non-localhost API because it doesn't have the newer endpoints added.

[Pasarus]

When testing this PR I assume you won't be able to do it using the non-localhost API because it doesn't have the newer endpoints added.

We will be able to once this PR is merged: fiaisis/FIA-API#251

I will get to reviewing PRs when I can, at the moment I have none-project work that needs to be completed.