This repository has been archived by the owner on Dec 12, 2020. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When new breaker is created via new
new CircuitBreaker({...})
,self._forced
isundefined
(notnull)
. Now when_executeCommand
gets called there is:Which will be interpreted as
if (undefined == null)
, which will betrue
, and library is on safe side. Now imagine that at sometime you will runeslint
against this code (http://eslint.org/docs/rules/no-eq-null) and replace above check withif (self._forced === null)
(which is anyway, safer than using just==
), whole library would be unusable, right? cause(undefined === null)
will lead tofalse
. Problem can easily be solved withif(!self._forced)
as proposed in PR, cause it will returntrue
ifself._forced
isundefined
ornull
.Other than that there is also proposal to use
===
instead of==
in whole lib, and also using string constants such asOPEN
,HALF_OPEN
andCLOSED
instead of0
,1
,2
, it improves readability, and if you decide to merge PR it is also must have, otherwise whenself._forced
is equal to0
, thanif (!self._forced)
would be interpreted astrue
because ofif(!0)
Tests results with proposed changes: