Closed amilner42 closed 7 years ago
It might be worth having common.api
have it automatically hooked up so everytime you make a request you're not allowed to make another of the same request till that one returns. Or to at least have this as an option, there are other places where the same problem will occur.
So it looks like the API will need to have it's own State. We can treat this similar to the State Monad in Haskell, just have the API also return an updated version of it's own state which can be plugged into shared
.
On top of this, it might be worth:
Having API be a type
instead of a type alias
, I haven't figured it all out yet but if I want to save requests automatically it'd be easier to write generic functions if everything was of the same type. The problem with the type alias is that each individual request isn't exactly connected to any of the other requests. This may or may not be a problem.
Having API switch to Task
s could be important, otherwise we won't be able to chain tasks reliably. If we're already refactoring, might be worth knocking out both these issues at once.
If we do have it be a type and we use Tasks, it would be nice for the API to expose methods such as makeRequest
and makeRequests
which would take in a Request
which would be from the type
.
Still undecided, but these are some initial thoughts.
Last option, and I'm thinking go with this, past of least resistance. When you make an API call, manually set that you're making that call. When it's done, set that it's done...
In future apps or in the future of this app I may change it, but I think for now picking the least resistance (and ironically most flexible) path is good enough.
If you click browse a ton, interestingly it'll copy the data and dup the data. This is because:
line: 42, file: browse/update.elm
When you get content, it sets currentContent to
Nothing
pre-request. But if you hit it twice fast and the first request doesn't come back yet.Solution: When fetching from the API and using "load more", set a boolean in the API for whether it's an initial request, use an api wrapper to pass that boolean back in the result so we know if the result was for an initial request. Use that information to decide whether to set/append, instead of checking whether we already have content or not.
Credit
Thanks to Banafsheh for finding this one!