Mash Browse copies data (Build API call-being-made system)

[amilner42]

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

        OnGetContentSuccess content ->
            case model.content of
                Nothing ->
                    justSetModel
                        { model
                            | content = Just content
                            , pageNumber = 2
                            , noMoreContent = isNoMoreContent 10 content
                        }

                Just currentContent ->
                    justSetModel
                        { model
                            | content = Just <| currentContent ++ content
                            , pageNumber = model.pageNumber + 1
                            , noMoreContent = isNoMoreContent 10 content
                        }

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.

1. Send first request, set Content to Nothing
2. Send second request set Content to Nothing
3. Receive first request, see Nothing, realize this is initial request, set the content.
4. Recieve second request, think it's now the result of a "load more" because we already have content so we must be fetching more. Append content

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!

[amilner42]

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.

[amilner42]

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 Tasks 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.

[amilner42]

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.