Spin Up a Proof-of-Concept for Automated Toasts, Based on Backend Responses

[klondikemarlen]

User Story

When the users complete action x, it pops up a toast that they have completed the action.

Constraints

The solution should be general and self contained. For example, using axios interceptors and a JSON schema to validate the api response format.

[klondikemarlen]

Options

1. Using axios interceptors and a JSON schema to validate the api response format.
2. Using generic error and success notifiers with minor customizability.

e.g.

api.get('some/url/')
      .then((data) => {
         // do something with data
      })
      .then(succesNotifier({ text: "Funding Period saved", variant: "success" }))
      .catch(failureNotifierFactory({ text: "Funding Period failed to save", variant: "error" }))

failureNotifierFactory could support additional complexity and have messaging per failure status code. Passing a custom message would set the error message for the 422 status with various other status having default messaging.

{
   422: { text: "Could not process content", variant: "error" },
   500: { text: "Server crashed", variant: "error" },
}

[klondikemarlen]

The dangers of tab + enter :P

[klondikemarlen]

Alternatively you could make the api object instantiation more complex and provide the success and failure messaging at that time.

e.g.

api = new FundingApi({
  toasts: {
    success: { text: "Funding Period saved", variant: "success" },
    failure: { text: "Funding Period failed to save", variant: "error" },
  }
})
api.get('/some/url')
   .then(() => {
     // do something with data.
   })

// FundingApi#get notifies automatically on success and failure.

[klondikemarlen]

Interceptors are very handy for certain things, but not so much for notifications, as most of the notifications need to be customized on a per-component, rather than a per-app or per-store level.

Most usage happens at the last lowest level, so we need a set of defaults that are easily customization at a given level.

[klondikemarlen]

Previous code I've worked with used the pattern. a) generic axios api setup [a.k.a client] with window level Authorization token (e.g. httpClient or axiosClient) b) simple object wrapper [a.k.a api] providing create/update/delete to a specific endpoint via the "client" (e.g. fundingPeriodsApi) c) stateful front-end cache [a.k.a. store], such as a pinia store, that uses the "api" (e.g. fundingPeriodsStore) d) in component usage of the "store" or "api" that triggers some kind of notification

I think the key problem here is providing clear definitions of the scope and responsibilities of each layer of the system, and having a notification system that provides both sane defaults, and easy customization.