Hard to understand App.js

[jaydenseric]

This is part issue, part question. I have been attempting to reverse engineer src/containers/App/App.js. Because everthing to do with auth (login, logout, conditionally displayed subcomponents) exists in the same file it is pretty hard to understand what code relates to what functionality.

What is the purpose of the logged_in meta tag? If you refresh the page after logging in there is a flicker from red to blue as the app first renders not logged in and then re-renders. This doesn't seem to be proper isomorphic rendering. If the server knows to set the logged_in value to true, it might as well go ahead and render everything correctly according to that state? How does the server know you are logged in after a refresh anyway, cookies?

I want to know how to conditionally display subcomponents anywhere in my app depending if the user is logged in or out, isomorphically. I am trying to pull out login to a page on a separate route. How would you restrict access to entire routes?

I don't think I have ever been so demoralized learning a new technology in my life. After 8 hours a day, 6 days a week for 2 months trying to work this out, with 12 fresh attempts, I am nearing the conclusion that universal JS apps are not commercially viable.

[bdefore]

You are right that this is not a shining example of isomorphic authentication. As implemented in this example, the serverside render does not know if a user is logged in. The client is naively rendering what it receives for login state.

Let me step through what it currently does:

• This JWT example specifies a custom head object to universal-redux by specifying in its configuration here: https://github.com/bdefore/universal-redux-jwt/blob/master/config/universal-redux.config.js#L151
• the application uses an express middleware, express-jwt-proxy, to login, logout, store and retrieve tokens. you'll see other implementations where tokens are stored in localStorage.
• the user session is persisted using a combination of redis and express-session (which identifies users on a connect.sid cookie)
• express-jwt-proxy adds a logged-in state boolean to response headers, based on whether a token is stored in redis
• universal-redux supplies the headers here: https://github.com/bdefore/universal-redux/blob/master/src/server/html.js#L18
• The client render uses the custom head object to check the meta tag for logged-in (which is assigned in universal-redux-jwt here: https://github.com/bdefore/universal-redux-jwt/blob/master/src/containers/Head/Head.js#L7)

As you mention, it should be possible to have server and client renders know the login state and enforce whether a user can even reach a certain route using react-router's onEnter feature. They have an auth flow example that uses it here: https://github.com/rackt/react-router/blob/master/examples/auth-flow/app.js#L135 .

This should all be in the README :/