when server error 500, the header menu item can not to Navigation

[taobataoma]

Hi, is this a bug?

when server error 500, the index render 500.server.view.html, but the top nav_bar menu can not to Navigation.

[simison]

Navigation should be visible as 500 uses layout which has html for navigation.

Do you get any JS errors in console?

[taobataoma]

NO， no any JS errors in console, I test it again, the 500 layout showing correct, but if used ui-sref in header.html, the navigation not work, if used href, such as <a href="/api/auth/signout" target="_self">Sign out</a> the navigation work fine.

[mleanos]

I'm able to reproduce this behavior if I navigate to http://localhost:3000/server-error directly.

This renders the 500 server view, which is (from my understanding) essentially what would happen if the application threw a 500 error internally.

So the first, and easy to fix, issue is that the user & sharedConfig objects are not being passed to the 500 template at time of rendering. This is what the causes errors at lines 63 and 75 shown in the above screenshot.

I was able to easily fix these errors pretty easily by adding the user and sharedConfig objects to the render method.

However, the real issue is that we're not using a ui-view directive (which is the container that holds the client-side views) with the 500 server template. See the differences between the index template and 500 template. Now every client-side action (short of a hard refresh) continues to use the 500 template as the view. You'll notice that the state changes do occur when using the nav, but the view never gets updated since we don't have a container for it.

We could add a <section ui-view></section> to the 500 server-side template. But this seems weird to me. Because either we want a true server-side view rendered in cases of 500 errors, or we redirect the user to a 500 error client-side route. Similar to how we're handling other 400 errors.

I don't really see a point to having the server-side templates, since we're handling all errors server-side using the Express error middleware.

@simison @lirantal Any insight into this?

[lirantal]

I think having a server-side rendering for errors makes sense just because they are then easily cached and handled by proxies and static web servers and don't really need to hit node.js all the time.

[mleanos]

@lirantal Could you elaborate? I do see the benefits of having server-side rendering in some cases; perhaps MEANJS is a one of them. However, I've always wondered what the true benefits of rendering server-side templates are.

As for the issue at hand, I'm not exactly sure how to reconcile this limitation of our current server-side template implementation. Any suggestions?

[lirantal]

I don't think it's a strong requirement to do server-side, but generally since error pages are usually static with no real javascript fancy stuff, then why would you want to hit the browser to render an 404 or 500 error if the server can easily do it? taking a step further, as you can imagine large scale websites may face a lot of users hitting those pages. they wouldn't want to actually hit the backend layer to render the view so they take another step and offload the rendering of such error pages to a static file web server, and then to a reverse proxy that can cache it.

There are many optimizations there, which is why I don't think it's a strong requirement for us since MEAN.JS isn't competing on these levels.

[mleanos]

@lirantal Thank you. What you're saying definitely makes sense. I tend to view the purpose of the server-side of MEANJS to be solely an API. This is why I've advocated for separating the client-side from the server-side. However, I respect the optimization considerations. I'm just not exactly sure where I land on that spectrum.

In our case, we're rendering a complete template (minus the ui-router) with header with the /server-error server view; i.e. angular, css, and other assets are still loaded. So I wonder of the benefit of this implementation. Should we move away from server-side rendering?

The way we're handling the errors server-side really makes it easy for many different different types of clients to interact with, and receive the appropriate response (whether error or not). For me this is the benefit of API's; they can be agnostic to any browser/rendering considerations.

In order to fix this bug we need to make changes to our current implementation. I see a few options..

1. Do away with server-side rendering
2. Include the ui-router in every server-side template
3. Provide a redirection link in the Error & 404 server-templates

[simison]

All 3xx, 4xx and 5xx error responses should really be "content negotiated", meaning that if the browser is asking for html content — return html content. If the browser is asking for a json content, return json instead of blob of html (current situation).

See example and Express.js docs for res.format().

[mleanos]

@simison Well, you just learnt me something new with the content negotiation! Thanks 😀

The implementation from Trustroots looks really good, and most likely the direction we should take in lieu of abandoning server-side rendering at this point.

[mleanos]

Although, I wonder now, IF an implementation of "content negotiation" in our Express router is exactly the solution (and argument) for moving away from server-side templates.. 😕

EDIT: Ok. I guess content negotiation SHOULD include a case where a server-side template is rendered. So my last point of moving away from server-side templates isn't very convincing.

[simison]

@mleanos Server side templates are great for email templates, too. ;-)

Feel free to copypaste! Here's stuff for 404