5 ms·

Feels like the author misses the point of an SPA. If you have website where every "view" is a /page/a etc., SPA might not be the best choice. But in an SPA i ca

Feels like the author misses the point of an SPA. If you have website where every "view" is a /page/a etc., SPA might not be the best choice. But in an SPA i can be dynamic, and trigger data retrieval/sending without route changes. A very basic example is if I have a checkbox that allows the user to subscribe to push notifications. On click I sent a xhr request to the backend POST `/subscribe/1234` which registers the subscription. Next time I'll check `/subscriptions` or similar to see if the checbbox is in "checked" state (i.e. we are subscribed). This is basic functionality which requires a concise REST/JSON API, and has nothing todo with your page/route layout à la /page/a, /page/b etc.

hakunin 3y ago
Author here. We do this for SPA. The POST can be supported just like you explained. Then you can either reload the "page" to see that the checkbox is checked, because backend will include that as part of the page, or (as an optimization) reload just that checkbox if you created a specialized resource for it. The entire page is still there for you to fetch upon transitions. Among pages, you will still need a few individualized resources sprinkled around for optimizations/reloads/fragment-paginations. The difference between that and a complete API is that they will be entirely design driven. If a table needs paginating, and is built with data from multiple resources, you will not provide 2 resources, and expect front-end to paginate and glue them together. Instead, you provide a complete paginated resource for this table, where data is ready to be displayed as-is.
- littlecranky67 3y ago
  That us exactly how stuff worked around 2005. And no, you should not do a full form post just to toggle a checkbox.
  - yakshaving_jgt 3y ago
    Why not?
    - valenterry 3y ago
      As a user, I can think if a couple of reason immediately: - I don't like page (re)loads. They are usually slower and more likely to fail, compared to a lightweight request. Especially in scenarios with a bad connection - If they fail, it's harder to retry, I see a connection timeout page. With a SPA I see an error message, potentially with a retry button. Or even better: the SPA retries for me a few times. - I can continue to see all the rest of the page while the action is running - I can potentially start other actions in parallel - I prefer to not lose any progress of things on the side, e.g. text-boxes where I already entered/changed some text - It's easier to inspect what goes wrong by looking at the network tab. Okay, most users don't do that, but for me it's still a pro There are also advantages, but I think nowadays the cons outweight those for me.
      - yakshaving_jgt 3y ago
        I’m convinced this is HN-themed satire.
        9935c101ab17a66 3y ago
        It seems sincere — unlike your comment, which comes across as very off-hand / dismissive.
        yakshaving_jgt 3y ago
        Yeah, sorry, but I just don't agree with the spirit of the comment, and I think it's thinking like this which leads programmers to over-engineer web applications, which usually harms user experience and wastes company money. Absolutist statements like "no, you should not do a full form post just to toggle a checkbox" are just silly. There is no minimum bound beneath which a standard web browser form submission doesn't make sense, and writing extra JavaScript code to not only manage an asynchronous network request but also handle subsequent behaviours for success, failure, timeout, etc., is additional complexity which incurs additional cost and a greater potential for system failure. Sometimes these implementation details and associated costs are necessary, but in most cases they aren't, and it's not an ideal perspective economically to default to the more expensive and complex implementation, especially for dubious benefit.
Falmarri 3y ago
Having form elements automatically update the back end is extremely annoying UI imo. There's usually no indication that it's actually doing that, and if there is I generally don't trust it.

hakunin 3y ago

Author here. We do this for SPA. The POST can be supported just like you explained. Then you can either reload the "page" to see that the checkbox is checked, because backend will include that as part of the page, or (as an optimization) reload just that checkbox if you created a specialized resource for it. The entire page is still there for you to fetch upon transitions. Among pages, you will still need a few individualized resources sprinkled around for optimizations/reloads/fragment-paginations. The difference between that and a complete API is that they will be entirely design driven. If a table needs paginating, and is built with data from multiple resources, you will not provide 2 resources, and expect front-end to paginate and glue them together. Instead, you provide a complete paginated resource for this table, where data is ready to be displayed as-is.

littlecranky67 3y ago
That us exactly how stuff worked around 2005. And no, you should not do a full form post just to toggle a checkbox.
- yakshaving_jgt 3y ago
  Why not?
  - valenterry 3y ago
    As a user, I can think if a couple of reason immediately: - I don't like page (re)loads. They are usually slower and more likely to fail, compared to a lightweight request. Especially in scenarios with a bad connection - If they fail, it's harder to retry, I see a connection timeout page. With a SPA I see an error message, potentially with a retry button. Or even better: the SPA retries for me a few times. - I can continue to see all the rest of the page while the action is running - I can potentially start other actions in parallel - I prefer to not lose any progress of things on the side, e.g. text-boxes where I already entered/changed some text - It's easier to inspect what goes wrong by looking at the network tab. Okay, most users don't do that, but for me it's still a pro There are also advantages, but I think nowadays the cons outweight those for me.
    - yakshaving_jgt 3y ago
      I’m convinced this is HN-themed satire.
      - 9935c101ab17a66 3y ago
        It seems sincere — unlike your comment, which comes across as very off-hand / dismissive.
        yakshaving_jgt 3y ago
        Yeah, sorry, but I just don't agree with the spirit of the comment, and I think it's thinking like this which leads programmers to over-engineer web applications, which usually harms user experience and wastes company money. Absolutist statements like "no, you should not do a full form post just to toggle a checkbox" are just silly. There is no minimum bound beneath which a standard web browser form submission doesn't make sense, and writing extra JavaScript code to not only manage an asynchronous network request but also handle subsequent behaviours for success, failure, timeout, etc., is additional complexity which incurs additional cost and a greater potential for system failure. Sometimes these implementation details and associated costs are necessary, but in most cases they aren't, and it's not an ideal perspective economically to default to the more expensive and complex implementation, especially for dubious benefit.

Falmarri 3y ago

Having form elements automatically update the back end is extremely annoying UI imo. There's usually no indication that it's actually doing that, and if there is I generally don't trust it.