For invalid href and route name, only throw error in development env,… #505
Conversation
… render null in prod with console error
|
CLA is valid! |
| var navigateAction = require('../../../').navigateAction; | ||
| var RouteStore = require('../../../').RouteStore; | ||
| var ORIG_NODE_ENV = process.env.NODE_ENV; | ||
|
|
| delete global.document; | ||
| delete global.navigator; | ||
| process.env.NODE_ENV = ORIG_NODE_ENV; | ||
| } |
There was a problem hiding this comment.
refactor the logic in old beforeEach to be able to share between 3 test suites.
| </MockAppComponent> | ||
| ); | ||
| }).to['throw'](); | ||
| }); |
There was a problem hiding this comment.
moved out into 2 other test suites (one for dev env, the other for prod env) to test diff behaviors in diff environments.
| var RouteStore = require('./RouteStore'); | ||
| var debug = require('debug')('NavLink'); | ||
| var navigateAction = require('./navigateAction'); | ||
| var __DEV__ = process.env.NODE_ENV !== 'production'; |
There was a problem hiding this comment.
We have typically inlined this and used webpack to replace process.env.NODE_ENV.
There was a problem hiding this comment.
ha. Stole it from fluxible. Dont think it is inlined there.
webpack will replace here as well. And I thought we had concerns about accessing process.env.NODE_ENV on every invocation of a hot function (like NavLink render). Maybe that is no longer a concern?
|
I've always been a fan of throwing for developer errors, but I'm don't feel strongly enough to reject this. |
|
@mridgway I hear you. We had a production outage this morning because one of the link (out of many links) on the page failed to render. And it crashed the node processes. That is essentially what triggered this PR. We could ask NavLink users to validate href/routeName ahead of using NavLink. But a little hard to scale as every NavLink has to run the validation check :( With this PR, we are still throwing in dev environment. (Granted, NODE_ENV dev environment is not the same as non-prod env in CI/CD pipeline :( ) Maybe I should figure out a way to do that instead. Throw in all non-prod CI/CD pipeline. I'm open for better suggestions for sure. |
| } else { | ||
| var logError = (this.context.logger && this.context.logger.error) || console.error; | ||
| logError('Error: Invalid NavLink, skip rendering...', props); | ||
| return null; |
There was a problem hiding this comment.
instead of returning null, I'm thinking if we should just render empty href, and when user click, should return here https://github.com/yahoo/fluxible/blob/master/packages/fluxible-router/lib/createNavLinkComponent.js#L262 and fallback to native anchor behavior with empty href.
rendering null might break some visual experience if this happens unfortunately
There was a problem hiding this comment.
I like that. Updating. @kaesonho
There was a problem hiding this comment.
Done. @kaesonho Check it out :)
|
👍 |
|
@mridgway @redonkulus more thoughts on this PR? I updated the PR to render with provided href prop in prod env (in the error case), instead of rendering null. |
|
👍 |
… render with empty href in prod with console error
Avoid crashing node process/ui thread in production just because one NavLink is configured wrong.
Will backport to 0.4.x after this PR is reviewed.
@kaesonho @mridgway @redonkulus