Where should we place the error boundaries for the toast system?

[seancolsen]

Seeking a decision

@pavish said:

we hadn't decided on where to place the error boundaries for the toast system... We could do it on the store, or even within the api layer of the store based on the pattern we discussed. This needs to be decided when we take up the toast system.

We need to decide on a pattern for consistently placing an error boundary, after which we can expect that all errors will be handled.

[seancolsen]

I feel somewhat strongly that this boundary should be within the component layer. That means that functions in the store layer will be expected to throw errors, and it means that we should never be calling the toast system from within the stores layer or utils functions.

[pavish]

I put some thought into this. I also think that the toast system should only be called only within the the view layer, which includes both components and utils.

There needs to be a clean separation of concerns with the data and the view layers, where the dependency should only be from view (component + utils) to data (stores) and not the other way around.

However, the util layer may operate on top or with conjunction to the component layer, for eg., the importUtils.ts file. It may also be helpful for us if we can abstract away error handling with raising a toast message into a util of it's own. Something like:

toast(somePromise, { ...options });,

Where the toast util would be responsible for showing loading, success and error toast messages.

[pavish]

This dicussion makes me think that we might probably want to segregate utils into three categories, one that manipulate views, one that manipulates data, and one that is independent.

[seancolsen]

Pavish and I chatted about this today and decided to go with his approach

The toast system should only be called only within the the view layer, which includes both components and utils.

That means that no files outside of sections, components, and pages should call the toast system. And files within those directories should only call the toast system if they are specific to the view layer. Data-specific files should not call the toast system.