4 ms·

Legitimate question: if you have multiple pages, are you still actually creating an SPA ? That may be the problem that you're encountering, and I can sympathiz

Legitimate question: if you have multiple pages, are you still actually creating an SPA ? That may be the problem that you're encountering, and I can sympathize. Nobody wants to transfer state across page loads, it's a mess...

jolmg 8y ago
The reason we chose to make an SPA for the big project is that we wanted the back-end to work for multiple different types of front-ends, some potentially adding automations from the client side via the API. Who knows, were it not for that, we may have chosen a simpler HTML+jQuery design.
- jolmg 8y ago
  You know, TimJYoung, I think I may have misunderstood what you were asking. It's still one page that loads the initial HTML layout, javascript files, and HTML templates. What I meant by "page" in my original post were front-end "pages" that just modify the content of the main container tag in the actual page. I don't need to transfer state because it's already there. Clicking a link causes the framework to destroy the content in a tag, run some javascript functions that probably make some requests to the back-end and fill the tag with the "page" of the new front-end route. The problem is that because of front-end framework supposedly-helpful automagic, unexpected things happen due to keeping state from previous front-end routes.
  - TimJYoung 8y ago
    Ahhh, yes, in that case it seems like you might possibly be better off (and happier ! :-) ) with just using a page-oriented architecture. It seems like the client-side state is just getting in your way, as opposed to being helpful in any way. The way that I look at it is this: if you're going to do an SPA, then do it like you're writing a desktop client application: all content is manipulated on the client, the only requests to the back-end are for data (JSON/XML), and the client typically will maintain quite a bit of state. Complex applications that are ports of desktop applications and sit behind authentication dialogs are ideal candidates for SPAs. Here's an example case study of such an application from our company web site: https://www.elevatesoft.com/articles?action=view&category=ewb&article=case_study_environment_canada_weather_reporting_application https://www.elevatesoft.com/articles?action=view&category=ew... The one exception to this would possibly be something like an online manual/help browser application, in which you might be able to make an exception and have the content driven by an SPA, thus allowing for more control over advanced content navigation via a tree view or vertical menu. In general, though, if you find yourself needing to do a lot of history/page management, then that is a good indication that you might be trying to shoehorn a traditional, page-oriented architecture into an SPA.

jolmg 8y ago

The reason we chose to make an SPA for the big project is that we wanted the back-end to work for multiple different types of front-ends, some potentially adding automations from the client side via the API. Who knows, were it not for that, we may have chosen a simpler HTML+jQuery design.

jolmg 8y ago
You know, TimJYoung, I think I may have misunderstood what you were asking. It's still one page that loads the initial HTML layout, javascript files, and HTML templates. What I meant by "page" in my original post were front-end "pages" that just modify the content of the main container tag in the actual page. I don't need to transfer state because it's already there. Clicking a link causes the framework to destroy the content in a tag, run some javascript functions that probably make some requests to the back-end and fill the tag with the "page" of the new front-end route. The problem is that because of front-end framework supposedly-helpful automagic, unexpected things happen due to keeping state from previous front-end routes.
- TimJYoung 8y ago
  Ahhh, yes, in that case it seems like you might possibly be better off (and happier ! :-) ) with just using a page-oriented architecture. It seems like the client-side state is just getting in your way, as opposed to being helpful in any way. The way that I look at it is this: if you're going to do an SPA, then do it like you're writing a desktop client application: all content is manipulated on the client, the only requests to the back-end are for data (JSON/XML), and the client typically will maintain quite a bit of state. Complex applications that are ports of desktop applications and sit behind authentication dialogs are ideal candidates for SPAs. Here's an example case study of such an application from our company web site: https://www.elevatesoft.com/articles?action=view&category=ewb&article=case_study_environment_canada_weather_reporting_application https://www.elevatesoft.com/articles?action=view&category=ew... The one exception to this would possibly be something like an online manual/help browser application, in which you might be able to make an exception and have the content driven by an SPA, thus allowing for more control over advanced content navigation via a tree view or vertical menu. In general, though, if you find yourself needing to do a lot of history/page management, then that is a good indication that you might be trying to shoehorn a traditional, page-oriented architecture into an SPA.