BaragonUI -> React #210
Merged
BaragonUI -> React #210
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This puts the _visual_ part of the Group Detail page together. It doesn't have any interactivity yet and isn't actually connected to the data stores of the application as a whole, but it has the html together.
The slow part here was that there was an action being called but it was missing a reducer, so the results of the action weren't reflected in the state of the application. This bumps that so the `FetchGroup` action does get mirrored in application state, and everything turns out fine.
Wire together the modal to remove a traffic source.
Split the single large GroupDetail component into a single component connected to the state object and a lot of smaller pure components. In doing so, also injected the refresh behavior from the top-level `GroupDetail` component into the modals, rather than having the modals themselves perform the data fetches.
Initial steps at making the UI for the status page. I still need to wire it to the action to search by request, but the interface itself is in place.
`action` is actually a misnomer here; the search bar is just a routing tool. It doesn't actually have an associated action, it just interacts with `react-router`'s api.
Move the ReactDetail page over to React. There aren't really any actions on this page, so this is pretty much all of it.
Move to using react-router rather than directly modifying the `browserHistory` object. This way is just a little bit neater.
This principally involved changing where the destructuring was taking place; in particular, it moved if from the HOC binding into the beginning of the render method. If also involved adding a loading icon to handle when the UI had yet to finish the request, and dropping the global `_` from being included in the vendor bundle.
Finish off (most of) the visual portion of the ServiceDetail page. I still need to attach the interactions, including the modals, and I would like to tool around some more with the request history panel. The existing pane is filterable and can be paged through, and I would like to at least get filterable done. Unfortunately, that is probably going to involve making my own component rather than reusing the `UITable` component.
Attach the modals to remove upstreams, reload configs, and delete the modal to the service detail page. Still to be done is paginating and filtering the request history in the 'Recent Requests' panel.
This mostly involved adding property types to the components that I had made and not added property types to. In some cases it did involve correcting things that were imported and not used, or were the incorrect imports for a file.
Limit the number of results displayed at a time to 5, and add buttons so
that the user can page through the results. Also add a quick search box
to the table. Neither the paging not the search are nearly as nice as on
the existing system; in particular, the table doesn't have the "Showing
{} from {} (filtered from {})" text on the original, and the search uses
`fuzzy`'s default implementation, which means that the results can seem
a little bit off kilter.
Add a page that has a filterable table of all ELBs that are running. Currently has the filtering and paging working.
Add a page to show details for an ELB. This page has no interactions at all.
Involved two major changes: migrating the single-page utils code into the package utils code, and changing how the request submission was handled. In particular, w/r/t the latter, it had been the case that there as an action creator in the `api/services.es6` file that was responsible for sending remove upstreams requests. That has now been removed, in favor of delegating to the more general action creator in `api/requests.es6` that can handle any kind of request, and just creating the request body at the point where it is triggered.
Add the control to the top-right of the nav window to enable and disable `allowEdit` state. This PR will also contain the collapse functionality for the navbar.
Make the nav bar collapsible the same way as on the existing application. That way you can expand the navbar to see all the links on your phone, if you have a driving need to do so.
At the moment, this is just a list of the target groups and load balancers. I'm going to have to walk through this to see how much information I can actually pull out of the endpoints that I have for this. In any event, at the moment it is just two tables, one for target groups and one for load balancers. It doesn't have any interactivity or useful information on it at the moment, but is just a list of some of the attributes on the data that we are pulling back.
This just roughly duplicates the information that is available for classic load balancers, but for the target groups. I'm really going to need to play with this for a bit to get the presentation right. In particular, I would like the load-balancers thing to link to the ALB detail pages, but I have the ARNs, not the load balancer names (which is what I have been using). This is fine for some things because ARNs are guaranteed unique and names aren't, but it's less attractive. So I'm going to have to think about what to do here.
I had left the timestamps in worker lag and ELB worker lag as milliseconds, rather than providing a useful interpretation of them. This uses the same format as the exisiting system, where it appropriately chooses whether to display seconds or milliseconds, and will not display the time at all if it exceeds a certain threshold.
Formerly the code for the password input field was entirely duplicated from the code for the password and duration fields. This refactors that slightly so the input type can be configured in the same way, but it only uses the code for it once.
Add JSON buttons for both of them. Also change out the information in the TargetGroups table, removing the ARN and adding the protocol and port number that the TargetGroup listens on. This also includes a handful of small style changes like stripping out extra new lines and having consistent formatting in the router.
Add a modal button + dialog to edit a target group's health check. It doesn't _do_ anything at the moment except log whatever the input was to the console because I need to play around with the endpoints on the back end in order to more accurately map to our use case.
Add two search filter boxes to the `Albs` component, so that you can refine what you are looking on the target groups page. It may actually be worth splitting up the TargetGroups and ApplicationLoadBalancers into seperate pages, depending on how much information that we're winds up getting displayed on this page.
Works the same way as links from albs to target groups. In particular, it just pulls in data and generates a lookup table from ARNs to names, which is what we're using to identify these things. It does add the overhead of an extra AWS call and another HTTP call when loading the page.
Add a link to the `/albs` page to the navbar, to be shown when ELB sync is turned on.
I had created an API that is capable of serving ModifyTargetGroup requests, so I attached it the the UI that could modify target groups.
Reduces the number of services displayed in the paginated table to a slightly smaller number (15, the number on the existing display) and makes it so that the buttons are only displayed when `config.allowEdit` is set.
To make it look a little more like the existing services table, I added a small status icon that is based on the upstreams that each service has. I also added a 'Remove Upstreams' button to have parity with the existing services table.
Add a search bar to narrow down the services that are displayed on the service-list page.
In order to avoid duplicating the logic for what gets included in the buttons block of the services table, use a conditional expression inside of the react code sections, rather than using an if block to wrap the whole thing.
React - Services Table
Originally I was ignoring the rules except for the default rule associated with a listener. In the short term I'm not sure this would matter because we aren't using path-based routing, which is the only time I think it would really come up, but it really just wouldn't be good practice. This makes it so that the front-end asks the back-end for the associated actions and those actions will actually be displayed on the front-end.
In particular, I was URI encoding ARNS when they went out (in the wrong place, as it happens), and then expecting them to be keyed unencoded. This just takes away all URI encoding, so it shouldn't come up. This also fixes a variable name that didn't match what I had been expecting it to be.
When a request that modifies a service is submitted (eg, reload config, remove upstreams), it now redirects the user to the request detail page.
Slightly janky solution to the problem of correctly refreshing the known agents list. The UI was attempting to correctly reload the page after sending the DELETE request, but the GET request was coming back in between when the DELETE request was accepted and when it was processed. This artificially creates a slight delay so that the GET request resolves to the correct data.
The problem didn't have anything to do with stale data. I was triggering but not dispatching the actions to fetch new data. Oops.
There was a migration on the ELB support branch that meant that a field in the groups list JSON changed its name. The result was that the groups list page was using the wrong name for a field and returning all zeros. The detail page reports the fields value correctly, but the list doesn't.
I found the list of all baragon groups on one page to be a little bit overwhelming. I just cut it down in the same way as for the services table, where the table now is paginated to 15 items at a time and includes a search bar to make it a little easier to find the item that you're looking for.
Add search bar to groups page
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
/cc @PtrTeixeira bunch of stuff still needs finishing, but the general outline of it is all here.