{"push_id":2642507882,"size":5,"distinct_size":5,"ref":"refs/heads/issue574(reload-edit)","head":"2f15c0bd5c158933f0de578209df1576932bbc92","before":"64c3da226b9e2d8310cae531d1aed4d64408647c","commits":[{"sha":"757d5a532e5ae2a3de193c06c411b804be88d73e","author":{"name":"Scott J Dickerson","email":"ed87d9826f646dfe88813ed379fd24bc8f4ff282@redhat.com"},"message":"Start scheduler after login initial data load and refactor login saga\n\n - Since the refresh scheduler fetches data from the REST API, wait\n   until the login saga is successful before starting. This prevents\n   erroneous refreshes if the initial load fails or takes longer\n   then the scheduler delay.\n\n - Login saga refactored to unwind the nested if blocks and improve\n   readability.","distinct":true,"url":"https://api.github.com/repos/sjd78/ovirt-web-ui/commits/757d5a532e5ae2a3de193c06c411b804be88d73e"},{"sha":"fe82ea027afe548f9c2fe7864a950ec70257271c","author":{"name":"Scott J Dickerson","email":"ed87d9826f646dfe88813ed379fd24bc8f4ff282@redhat.com"},"message":"Refactor App init and react-router Page rendering\n\n - `App` component will wait for login to complete before rendering\n   routes. This will allow the route Pages to assume all relevant\n   login data needed is available so additional API calls may be\n   made.\n\n - Route titles (visible in the breadcrumbs) will show the requested\n   VM or Pool UUID until the VM or Pool name is available from the\n   store.\n\n - Each detail/edit route page will fetch the VM or Pool requested if\n   it is not already available in the redux store.\n\n - Each detail/edit route page will sit with only the app header and\n   breadcrumbs rendered until the VM or Pool is available in\n   the redux store. The \"Loading...\" indicator should be present\n   while fetching data.\n\n - Removed **isPool** prop from `VmDetail` since it can be derived\n   from other props.","distinct":true,"url":"https://api.github.com/repos/sjd78/ovirt-web-ui/commits/fe82ea027afe548f9c2fe7864a950ec70257271c"},{"sha":"cce40735cabcc45e33b4efb91b1e45a41ecce25a","author":{"name":"Scott J Dickerson","email":"ed87d9826f646dfe88813ed379fd24bc8f4ff282@redhat.com"},"message":"View and Edit pages will wait for their VM/Pool to be loaded\n\nIssue #574 was caused when a user would enter the app at a view\nor edit page with a VM or Pool that would be on a fetch page >1.\nThe VM/Pool would be requested but often would either fail the\nrequest or would not arrive prior the initial data load flag\nbeing set true. The concurrency issues would leave the user\neither on a blank page or redirected to the card view page.\n\nA number of changes, along with the refactoring of the App init,\nreact-router page rendering, and login saga, have been made to\n eliminate this issue:\n\n - The single VM fetch REST call can now __follow__ all the data\n   paths like the fetch by page does. This reduces the number of\n   REST calls required from 6 to 1. It now also supports both\n   shallow and deep fetches.\n\n - The __fetchSingleVm__ saga is upgraded to tag the VM IDs to\n   the redux state that it has successfully fetched\n\n - The __fetchSinglePool__ saga was upgraded in the same way\n\n - The redux store **state.vms** reducer can now keep track\n   of the VM/Pool IDs that are loaded independent of those loaded\n   by the paged loader. Actions and constants were added in\n   support of the reducer changes.\n\n - Selectors were added to fetch those 2 lists from the store\n\n - The __refreshData__ saga was upgraded so it refreshes both\n   the individually fetched and page fetched VMs and Pools\n   without dropping any of them from the redux store. The removal\n   of 'stale' VMs and Pools from the store was moved to this saga\n   so it can be done once and preserve ALL VMs and Pools regardless\n   of how they were fetched.\n\nUpdated the `refreshData` saga based on PR review comments\n\n - Calculate the IDs that need to be fetched individually instead of\n   tracking them in the redux store\n\n - Added parallel `fetchSingle*` calls to speed up the single item\n   fetch processing in `refreshData` should there be >1 item not\n   refreshed by the `fetch*ByCount` functions\n\n - Removed the `*FetchedById` states, reducers, actions and constants\n   since they're no longer needed\n\n - Adjusted the selectors to return all VM or Pool IDs currently held\n   in the store\n\n - Fixed a latent bug in the UPDATE_VMPOOLS_COUNT reducer in\n   __src/reducers/vms.js__\n\nNOTE: This change will cause `refreshData` to singly fetch an VM\nor Pool not fetched by the paged/by count functions. That could be\nfor any reason including, but not limited to, accessing a VM or Pool\nthat is past the first fetch page via direct URL (this PR's issue),\ndeletion of the VM or Pool, permission changes to the VM or Pool,\nor if the VM or Pool gets pushed past the last page the App is\ncurrently refreshing.\n\nTagged strings that require localization in the login saga","distinct":true,"url":"https://api.github.com/repos/sjd78/ovirt-web-ui/commits/cce40735cabcc45e33b4efb91b1e45a41ecce25a"},{"sha":"b2f0d1dbc12324385ac109525d606d3a0a1f84db","author":{"name":"Scott J Dickerson","email":"ed87d9826f646dfe88813ed379fd24bc8f4ff282@redhat.com"},"message":"Update the view/edit Page components to use `getDerivedStateFromProps`\n\n - To better handle updates to props from react-router navigation (or\n   page reloads), the `Page` components now track the VM/Pool they're\n   working with in component state.\n\n - Only when the react-router matched id is different from the Page\n   component's id will the VM/Pool be refreshed.\n\n - Moved the loading of console options out of `VmsListNavigation`\n   and put it in `VmDetailpage`.  The Page components are solely\n   responsible for refreshing the data needed for their view/edit\n   components.","distinct":true,"url":"https://api.github.com/repos/sjd78/ovirt-web-ui/commits/b2f0d1dbc12324385ac109525d606d3a0a1f84db"},{"sha":"2f15c0bd5c158933f0de578209df1576932bbc92","author":{"name":"Scott J Dickerson","email":"ed87d9826f646dfe88813ed379fd24bc8f4ff282@redhat.com"},"message":"Fixed the 'selecting VM details' unit test by initializing a mock store\n\nMoved the __env__ jest config from CLI to package.json properties\nso tests can be run in the background and debugged in vscode.\n\nChanges introduced in the previous commits cause the sagas being\ntested to need a mock store. Specifically the __selectors__ needed to\nbe initialized or they throw an exception. The initial state of reducers\nused by __selectors__ are now exported to be used in the unit test.","distinct":true,"url":"https://api.github.com/repos/sjd78/ovirt-web-ui/commits/2f15c0bd5c158933f0de578209df1576932bbc92"}]}
{"actor":{"display_login":"sjd78"}}