Finish UI portion of ServiceDetail page #214
Conversation
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.
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.
PtrTeixeira
changed the title
| ); | ||
| }; | ||
|
|
||
| const ButtonContainer = ({editable, serviceJson, upstreams, |
There was a problem hiding this comment.
might make sense to have this in it's own file since it's a separate component.
|
|
||
| // [T], PosInt -> [[T]] | ||
| // [1, 2, 3, 4, 5, 6, 7], 2 -> [[1, 2], [3, 4], [5, 6], [7]] | ||
| const chunk = (arr, size) => { |
There was a problem hiding this comment.
rather than having a separate util file in the serviceDetail folder, we should put these in the more global utils file. Seems plenty of these may be reused in components for other pages
| @@ -29,3 +31,20 @@ export const ReloadService = buildJsonApiAction( | |||
| url: `/state/${serviceId}/reload`, | |||
| }) | |||
| ); | |||
|
|
|||
| export const RemoveUpstreams = buildJsonApiAction( | |||
There was a problem hiding this comment.
we should make sure to add this action to the reducers as well, the returned output will be more easily accessible
| 'REMOVE_UPSTREAMS', | ||
| 'POST', | ||
| (loadBalancerService, upstreams, noValidate, noReload) => ({ | ||
| url: '/request', |
There was a problem hiding this comment.
there are several different actions that might submit a request. Maybe it makes sense to use the SubmitRequest action in requests.e6 and let each of the submitting processes handle generating the necessary body?
Feel free to disagree, just trying to think how to best organize what might be very similar calls from different places.
| removeUpstreams: upstreams, | ||
| }, | ||
| }), | ||
| (serviceId) => serviceId, |
There was a problem hiding this comment.
It would make more sense to have this keyed on the requestId. When fetching results for the request we are going to have to look it up by that id, not the serviceId
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.
| @@ -1,5 +1,7 @@ | |||
| import { buildApiAction, buildJsonApiAction } from './base'; | |||
|
|
|||
|
|
|||
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
UITablecomponent.