No, our pages make their own HTTP requests from within the page, and do not
delegate the top layer to make requests. The majority of our api requests
are done from within pages, and I think that's likely the case for most
apps. Each of our "pages" manage their own http errors through the use of a
reusable view module that displays errors in a popup modal. We COULD pass
401 errors upwards to the top layer to initiate a re-route to login, but we
don't - If a 401 hasn't been caught during the initial transition to a
page, it's unlikely that one is going to occur during the lifetime of a
single page. If a 401 does occur during a page api request, it's simple to
display a "please login" message in the popup error modal.
If you absolutely need to communicate all 401's upwards, just make that
part of the API of your page modules - that will involve sending an
'OutMsg' from your page's "update" function.
Happy to explain further if anything is unclear.
On Friday, September 16, 2016 at 6:17:24 PM UTC-4, Rupert Smith wrote:
> On Friday, September 16, 2016 at 6:07:42 PM UTC+1, Erik Lott wrote:
>> Rupert, here is a high level overview of how we currently structure our
>> elm SPAs:
>> 1. Top layer: This layer manages routing, page changes, and page
>> resource loading, and current user state
>> 2. Page layer: These are individual pages - typically one page for
>> each url. There may be deeper levels of widgets/views within each
>> page, but we don't have pages nested within pages.
>> When the top layer is notified of a page change (this mechanism can vary
>> from app to app), it first communicates with the backend server to load any
>> resources that are needed to display that page. If the resource load
>> succeeds, the page is displayed by changing the 'currentRoute' to the new
>> routing state, and providing the loaded resources to the new page. If the
>> load fails, however, you can check the http error to determine why. If
>> you're received a 401 failure, you can quickly change to your "login route"
>> and ask the user to login.
>> Keep in mind that method allows you to catch and mange http errors that
>> occur during page transitions, and not from http requests made from within
>> a page. We're fine with that tradeoff, because 99% of the time, you'll only
>> need to catch 401 during page transitions anyways.
>> Hopefully that helps.
> Very enlightening thanks.
> What about POSTs from pages? For example, I have a page which shows user
> accounts (to an admin), and will also allow a new user account to be
> created. It would seem natural to POST the new account from within that
> page. Or do you do that from the top-level too?
You received this message because you are subscribed to the Google Groups "Elm
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.