Moving from isomorphic to website causes render service error about react-pages

[catamphetamine]

I guess it wasn't but no guarantees. There has been a lot of previous versions.

[catamphetamine]

You could start with commenting out all @preload()s for a single route and then see if the error disappears.
If it disappears then uncomment those @preload()s from top to bottom and see which one errors.
Then comment it out and then uncomment it line-by-line to find the erroring piece of code.

[russellbits]

Thanks for the suggestion. I tried this—reducing the routes down to just the IndexRoute and commenting out any @preload function there but I still get the above errors. Incidentally the a promise was rejected with a non-error: [object Object] type errors do not show up until the page is reloaded in the browser. I tried shutting off javascript in the browser to get the server-side render to act alone. The whole HTML page just says "Error" with nothing in the console.

[catamphetamine]

@russellbits So it's not coming from a @preload() promise then...
And it happens in the server-side part of the code.

If you look at the source code in the library it's this:

./node_modules/react-pages/commonjs/server/renderError.js

import { html } from 'print-error'

// Outputs an error page
export default function renderError(error, options)
{
	// If the error is caught here it means that `catch`
	// (error handler parameter) didn't resolve it
	// (or threw it)

	// Show error stack trace in development mode for easier debugging
	if (process.env.NODE_ENV !== 'production') {
		try {
			const { status = 500, content } = renderStackTrace(error, options)

			if (content) {
				return {
					status,
					content,
					contentType: 'text/html'
				}
			}
		} catch (error) {
			console.log('[react-pages] Couldn\'t render error stack trace.')
			console.log(error.stack || error)
		}
	}

	// Log the error
	console.log('[react-pages] Rendering service error')
	// console.error(error)

	return {
		status: typeof error.status === 'number' ? error.status : 500,
		content: error.message || 'Error',
		contentType: 'text/plain'
	}
}

function renderStackTrace(error, options)
{
	// Supports custom `html` for an `Error`
	if (error.html) {
		return {
			status  : error.status,
			content : error.html
		}
	}

	// Handle `superagent` errors: if an error response was an html, then just render it
	// https://github.com/visionmedia/superagent/blob/29ca1fc938b974c6623d9040a044e39dfb272fed/lib/node/response.js#L106
	if (typeof error.status === 'number') {
		// If the `superagent` http request returned an html response
		// (possibly an error stack trace),
		// then just output that stack trace
		if (error.response
			&& error.response.headers['content-type']
			&& error.response.headers['content-type'].split(';')[0].trim() === 'text/html') {
			return {
				status  : error.status,
				content : error.message
			}
		}
	}

	// If this error has a stack trace then it can be shown
	const stack = getStackTrace(error)

	// If this error doesn't have a stack trace - do nothing
	if (!stack) {
		return {}
	}

	try {
		return {
			content : html({ stack }, options)
		}
	} catch (error) {
		console.error(error)
		return {
			content : error.stack
		}
	}
}

// Extracts stack trace from `Error`
function getStackTrace(error)
{
	// Standard javascript `Error` stack trace
	if (error.stack) {
		return error.stack
	}

	// `superagent` errors have the `original` property
	// for storing the initial error
	if (error.original && error.original.stack) {
		return error.original.stack
	}
}

You see there's a console.error() commented out there.
You can uncomment it and see what it outputs.

[russellbits]

Thank you. I could not find that error line before. Now I get
HttpError { status: 404, data: undefined } GET / 404 197.134 ms - 5

That's a bit more helpful.

[russellbits]

Does the @preload decorator have to use async/await? If it's not, could that be causing the Warning: a promise was rejected with a non-error: [object Object]

[catamphetamine]

Does the @preload decorator have to use async/await?

It's not clear what you mean.

[russellbits]

In your docs you mention "@preload() decorator takes an async/await function which takes an object of arguments," say, {preloadArugments}. I'm wondering if that always has to be the case.

[catamphetamine]

Yes. It doesn't say can take, it says takes.

[russellbits]

Do you recall if that was the case with the older package (react-isomorphic-render)?

[russellbits]

Your server-side-render example does not use the same asynSettings that my app does.

import {underscoredToCamelCase} from 'react-website';

export default {
    // When supplying `event` instead of `events`
    // as part of an asynchronous Redux action
    // this will generate `events` from `event`
    // using this function.
    asynchronousActionEventNaming: (evt) => ([
        `${evt}_PENDING`,
        `${evt}_SUCCESS`,
        `${evt}_ERROR`
    ]),

    // When using `asynchronousActionHandler`
    // this function will generate a Redux state property name from an event name.
    // E.g. event `GET_USERS_ERROR` => state.`getUsersError`.
    asynchronousActionHandlerStatePropertyNaming: underscoredToCamelCase
};

This gets imported into my more typical react-website.js settings along with reducers. I'm not sure if this could be interfering with react-website's built-in events for preload...

[catamphetamine]

asyncSettings are no longer required.
I'd suggest removing them from code.