4 ms·

I thought the parent poster was referring to his own apps, not others'? It's trivial to provide progress and retry capabilities, especially if you're using Red

I thought the parent poster was referring to his own apps, not others'? It's trivial to provide progress and retry capabilities, especially if you're using Redux where you can build retrying into the reducer pipeline itself instead of reimplementing it for every use case. With React/Redux I recommend integrating it into a reusable component such as this: <ProgressStatus task={this.props.save}> <Button label="Save" onClick={this.props.dispatch(save())}/> </ProgressStatus> Here, ProgressStatus is a high-level component that renders a progress spinner or similar if it's "task" is busy, otherwise displays its children. So the moment anyone clicks the save button, the save button will be replaced with a spinner. You can also build this directly into the button component and make it disabled while it's busy. Of course a lot of SPAs are less great at dealing with slow/bad connections. I find Google's apps to be particularly bad at this.

mattmanser 10y ago
It is "trivial", "easy", "simple". I've become increasingly distrustful of your view point as you've simply just kept replying to a load of different replies saying otherwise that everything's so easy, when it's not. It's all adding extra complexity. It's absolutely laughable for you tell people that a great solution is adding an API. Boom, extra layers of complexity. Connection problems? Add progress spinners! Progress spinners are yet another complication you have to constantly think around and with deal in SPAs, not something to be celebrated. And what do they actually do? Apparently you don't split your code up? I deal with 1500 line files in a project because of what came before, not splitting it up would be an even greater disaster. It's beginning to sound like either you work on trivial month or two projects, or you don't work with other people.
- lobster_johnson 10y ago
  There's no need to get nasty and personal. Of course I work with other people. I've been working on multiple (I'm counting at least 6) complex React apps for about 4 years now. Our largest React UI app is about 40kloc lines. Before that most of the apps I worked on were large Rails or Sinatra apps. 1500-line files are not desirable. My point was that you have to choice whether to split up files or not, exactly the same way that you would do in a non-SPA app. The reason for using words like "trivial" isn't to belittle problems, but because these are solved problems. You describe them as though they're painful hurdles, and I simply disgaree. Describing a component as "adding an API" is disingenuous, considering that it solves a problem and is — yes — trivial and completely reusable. You would have to do the same thing in a non-SPA application if you're submitting data to an API via XHR, of course; you also have to handle connection errors there. If you're doing a "web 1.0" form that submits to a new page, it turns out modern browsers aren't particularly good as display progress or recovering from errors, either. I'd say the XHR/SPA approach gives a better UX here: In my SPA I can store a "draft" object to localstorage, display a nice progress spinner, show an error message and a "retry" button on connection errors, and recover the draft again in case the user accidentally lost the page.

mattmanser 10y ago

It is "trivial", "easy", "simple". I've become increasingly distrustful of your view point as you've simply just kept replying to a load of different replies saying otherwise that everything's so easy, when it's not. It's all adding extra complexity. It's absolutely laughable for you tell people that a great solution is adding an API. Boom, extra layers of complexity. Connection problems? Add progress spinners! Progress spinners are yet another complication you have to constantly think around and with deal in SPAs, not something to be celebrated. And what do they actually do? Apparently you don't split your code up? I deal with 1500 line files in a project because of what came before, not splitting it up would be an even greater disaster. It's beginning to sound like either you work on trivial month or two projects, or you don't work with other people.

lobster_johnson 10y ago
There's no need to get nasty and personal. Of course I work with other people. I've been working on multiple (I'm counting at least 6) complex React apps for about 4 years now. Our largest React UI app is about 40kloc lines. Before that most of the apps I worked on were large Rails or Sinatra apps. 1500-line files are not desirable. My point was that you have to choice whether to split up files or not, exactly the same way that you would do in a non-SPA app. The reason for using words like "trivial" isn't to belittle problems, but because these are solved problems. You describe them as though they're painful hurdles, and I simply disgaree. Describing a component as "adding an API" is disingenuous, considering that it solves a problem and is — yes — trivial and completely reusable. You would have to do the same thing in a non-SPA application if you're submitting data to an API via XHR, of course; you also have to handle connection errors there. If you're doing a "web 1.0" form that submits to a new page, it turns out modern browsers aren't particularly good as display progress or recovering from errors, either. I'd say the XHR/SPA approach gives a better UX here: In my SPA I can store a "draft" object to localstorage, display a nice progress spinner, show an error message and a "retry" button on connection errors, and recover the draft again in case the user accidentally lost the page.