fix(alerts): update to display all alerts

[jsundquist]

Previously alerts would only display the first 50 results. This change updates it so that alerts and incidents acts the same in fetching all available alerts stored within Ops Genie.

I plan on updating both the alert table and incidents table as well to allow users to filter the results a little better as well. This is the initial step needed. Essentially right now the load time is incredible to load up both all incidents and alerts. One idea I have for the two tables is to initially only load those incidents or alerts that are open, after that allow users to see either all, open, closed, or resolved for incidents and open, acknowledged or closed for alerts.

[K-Phoen]

Thanks for opening this PR!

I absolutely agree with you, both the incidents and alerts lists could use some love. Being able to explore all the data with decent filtering capabilities would indeed be a good start.

I also appreciate your effort to start with a smaller PR, taking one step in that direction.

That being said, this PR changes the behavior of the alerts table and the EntityOpsgenieAlertsCard component in a way that would make both unusable, so I'm reluctant to merge it as-is.

Instead of loading as many alerts as we can in memory and then displaying them, what if we made the table a bit more dynamic?
With the "remote data" feature of material table, we should be able to load small chunks of data at a time, while still being able to retain filtering/sorting capabilities. WDYT?

[K-Phoen]

This will change the behavior of the EntityOpsgenieAlertsCard component.
It currently displays only a maximum of 3 alerts for a given entity, but this change will make it display every alerts related to that entity.

This is because AFAIK, the limit parameter accepted by Opsgenie applies to a result page, not the overall search.

[jsundquist]

Thanks for opening this PR!

Of course, sorry for taking so long to reply back to your comments.

I absolutely agree with you, both the incidents and alerts lists could use some love. Being able to explore all the data with decent filtering capabilities would indeed be a good start.

👍

I also appreciate your effort to start with a smaller PR, taking one step in that direction.

That being said, this PR changes the behavior of the alerts table and the EntityOpsgenieAlertsCard component in a way that would make both unusable, so I'm reluctant to merge it as-is.

Completely agree with this statement. I was a little hesitant about putting it forth as I knew it would be pushing it a bit further than what the component currently can handle. It also would pull in more data that what most browsers could handle depending on the number of alerts a system has triggered.

Instead of loading as many alerts as we can in memory and then displaying them, what if we made the table a bit more dynamic? With the "remote data" feature of material table, we should be able to load small chunks of data at a time, while still being able to retain filtering/sorting capabilities. WDYT?

Using the remote data table looks like it could be a great option to remove the breaking nature that this PR puts forth. I'll take a look at material table to implement the remote data fetch.