Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

manually inserting Exception #13

Open
vaudevillen opened this issue Jul 28, 2020 · 4 comments
Open

manually inserting Exception #13

vaudevillen opened this issue Jul 28, 2020 · 4 comments

Comments

@vaudevillen
Copy link
Collaborator

So was thinking if we can call Bismarck.insert(Data), for whenever we might need to manually update Bismarck data, it might also be necessary to manually insert an error response.

For example, if the Fetcher just makes a get request, but later we need to make a put or a post, we would need to do that manually. If that network request has an error, shouldn't we also send that through to the eachError callback?

@asarazan
Copy link
Owner

I'm open to this idea, but it does have a whiff of broken abstraction to it. @treelzebub do you perchance have an opinion on this?

@treelzebub
Copy link
Collaborator

treelzebub commented Jul 30, 2020

whoa i've missed a whole bunch of big changes up in hurrr. didn't know Fetcher was just a lambda now, but i'm into it. we've made error propagation Bismarck's job when it used to be Fetcher's, and imo that's a great move that gets rid of a bunch of duplicated effort.

to the question at hand, i'm not sure i understand: why would you want to insert an exception, and how would that even work if you have a Bismarck<MyDataClass>? i'm having trouble understanding how network errors getting fed to eachError is related to caching those errors.

@asarazan
Copy link
Owner

@treelzebub if you recall in the level days, we would do "optimistic" mutations on transactions, and that would involve injecting an updated value into the local store while we await the canonical value from a fetch.

Given that there is a good reason to override the authority of the data store, I think it definitely stands to reason that we might want to reflect a failed external operation here-- but similarly, this may just be an argument for punting the responsibility to the client to create a higher-level aggregator of errors, which is composed of bismarck errors, other systems etc...

@treelzebub
Copy link
Collaborator

treelzebub commented Jul 31, 2020

punting the responsibility to the client to create a higher-level aggregator of errors, which is composed of bismarck errors, other systems etc...

this is kinda where i'm going with this. in my mind it's trivial to put your reactive element in the fetcher and propagate errors yourself. unless, of course, you're using LiveData, which is a thing that should in fact support error handling :P

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants