Closed stephenbaldwin closed 3 years ago
I'm thinking we provide a built in reducer and action that allow for change of status code
@stephenbaldwin i agree that status codes are not always truthful right now. a difficulty is that UR is agnostic to the server implementation and may not be able to accurately glean the status. should it always proxy along the status code of the data fetch? if there are multiple?
RRUHE uses this, but I believe it is not compatible with RR2: https://github.com/erikras/react-redux-universal-hot-example/blob/master/src/server.js#L108-L111 https://github.com/erikras/react-redux-universal-hot-example/blob/master/src/helpers/getStatusFromRoutes.js
I don't think that solves the problem either. That still only allows the route to display status code. I'm thinking something more along the lines of
import { pageNotFound } from 'universal-redux/helpers';
export default class extends Component {
static fetchData(getState) {
const { articles: { error } } = getState();
if (error) {
pageNotFound()
}
}
}
#pageNotFound
would dispatch the action of PAGE_NOT_FOUND, a built in hidden reducer inside of UR would listen for the PAGE_NOT_FOUND event, and update the state. UR on rendering the component would check the contents of it's internal hidden state and if a custom status code exists, it would send that as the code.
what are your thoughts
let's circle back on this @bdefore. This issue will stop any major company who is concerned with SEO from adoption. Currently any error or 404 will result in the page rendering a 500 that only contains "{}". I've got a working solution but we should discuss before i start throwing up PRs to make sure we're in agreement
An action must be provided to update the status code rendered from the server. Route matching is not enough. For example:
In the example above, the route successfully matches but the data is not found and the header still responds as successful. We must provide developers the ability to trigger a status code on the server