Is your feature request related to a problem? Please describe.
The map component makes requests whenever the collection of interest changes. However, as part of the State lifecycle, sometimes the data used to make the request is set to placeholder data, which is invalid for requests. This creates erroneous requests and errors. This makes it difficult to manage true errors. It also makes unnecessary work for the server, checking errant requests.
Describe the solution you'd like
There are guards in place to prevent calls with errant data. We should also have a state that indicates the values have been reset and we need fresh data.
Describe alternatives you've considered
The component could be restructured to make requests by specifically calling functions, rather than watching for state changes. However, the logic for managing these function calls quickly becomes convoluted, given how the state of the application can. Instead, we are able to keep each api call de-coupled from the others by instead coupling them to changes to new valid states.
Also, if we do not reset old data, there will be a lag where the application has old, unwanted data, sitting in the application, while waiting to get the fresh data.
Additional context
By adding a state that indicates we are waiting for data, we can also update the child components to recognize this state and provide user feedback, as appropriate.
By more gracefully handling errors, we can also reliably provide error feedback to users.
Is your feature request related to a problem? Please describe. The map component makes requests whenever the collection of interest changes. However, as part of the State lifecycle, sometimes the data used to make the request is set to placeholder data, which is invalid for requests. This creates erroneous requests and errors. This makes it difficult to manage true errors. It also makes unnecessary work for the server, checking errant requests.
Describe the solution you'd like There are guards in place to prevent calls with errant data. We should also have a state that indicates the values have been reset and we need fresh data.
Describe alternatives you've considered The component could be restructured to make requests by specifically calling functions, rather than watching for state changes. However, the logic for managing these function calls quickly becomes convoluted, given how the state of the application can. Instead, we are able to keep each api call de-coupled from the others by instead coupling them to changes to new valid states.
Also, if we do not reset old data, there will be a lag where the application has old, unwanted data, sitting in the application, while waiting to get the fresh data.
Additional context
Labels
needs definitionneeds helpready to work onin progressbacklogFor Developers
Affected Components Map, its children, and tests
Technical Resources MSW for testing
Design Documentation Use existing design language
Testing Outline MSW for testing