JavaScript is the most commonly used programming language and has been at the top of the GitHub annual highlights. Its open source ecosystem will be much bigger as it is widely applied to developing server, mobile, and desktop applications beyond just websites.

While code bases written in JavaScript are larger, debugging and managing the code bases are getting more difficult especially due to the dynamic features of JavaScript language. But you can significantly reduce this quality cost by catching code defects at the earlier stage of the development cycle.

Static analysis tools come into play at this stage.

To help JavaScript folks find static analysis tools helpful, we rummaged our database regarding run-time errors and code smells found by our JavaScript static analysis tool. It was gathered by analyzing code from thousands of public JavaScript and TypeScript projects on GitHub.

This whitepaper describes how static analysis tools work and shows some types of problems that static analysis tools can prevent. Feel free to download the whitepaper for a look on how static analysis tools cope with the troubles of JavaScript.

Detecting JavaScript Errors and Code Smells with Static Analysis was originally published in DeepScan on Medium, where people are continuing the conversation by highlighting and responding to this story.

Recently, I saw an awful comic about the coding pitfall.

After some laugh, I regretted not having shared our experiences and practices about coding pitfall. The scientists would have been alive if they knew this rule, RIP.

Okay, let’s get down to business.

As can be seen from the GitHub statistics recently announced, JavaScript is very popular. However, because of its dynamic nature, JavaScript is more challenging to manage its code quality as codebases become larger.

With this concern, I have developed a JavaScript static analyzer (DeepScan) that finds potentially error-prone code without executing the code. Instead of detecting mere code convention violations, it tries to find ECMAScript exceptions and common mistakes developers make.

For benchmarking the analyzer, we have applied it to in-house projects and also to various open source projects in GitHub. Although the analyzed sources are committed ones after local development, there are still some errors not caught by human developers and testing.

In this article, I’ll share common pitfalls found in the benchmark. I hope this article will give you some insight on what you consider in JavaScript development.

1. Misuse of typeof operator

Possible return values of typeof operator are the following strings:

• “undefined”
• “object”
• “boolean”
• “number”
• “string”
• “symbol”
• “function”

Unlike the right operand of instanceof in Java, it’s not arbitrary. When a developer compares with the value not listed above, it will always result in false undesirably.

I found some developers seem to use typeof operator to check if an object is an array type.

var param = typeof pChangeMessageList == "Array" ? pChangeMessageList.join('|') : pChangeMessageList;

Isn’t it natural?

But, “Array” (or “array”) is not a valid return value of typeof and pChangeMessageList will not be joined even when it is really an array. Developers should use Array.isArray() or utility functions in jQuery, lodash, ….

Also, because the return value is a string, typo is common.

In Apache Ambari, let’s see a typo udefined: app/controllers/main/host/details.js

In other projects, I also could see typo like undeifned.

if (typeof Object.prototype[k] != "undeifned" && Object.prototype[k] === this._table[k]) continue;

Pleasantly, I found above problems were fixed by the refactoring commit like this.

Note that typeof operator returns a predefined string only.

2. Use of undeclared variables

Let’s look at the example first. (Our in-house code)

var rows = [];
for (var i = 0; i < args.length; i++) {
    var obj = {
        patternId: patternId
    };
    rows.push(obj);
}

var patternId = $("#pattern").attr("patternId");
$.post('/delete.do', { data: JSON.stringify(rows) });

Since patternId variable is used before its declaration and assignment, obj has a wrong value.

In Java, the compiler will grumble about this “Unresolved variable” case. But the lifecycle of JavaScript variables allows above prior-usage pattern because patternId variable is hoisted and initialized as undefined immediately when the surrounding function is executed.

Just use let. It will throw ReferenceError(“patternId is not defined”) and you cannot send erroneous data to the server at least.

I recommend you read this article about var hoisting. Frankly, I did not know exactly the difference between var and let.

For your information, this is why some JavaScript coding conventions say a developer should declare all the variables in the beginning of function body.

3. Unused and Uninitialized variables

Unused variables can cause a problem. Below in-house code was appending userName parameter and trimming special characters.

if ($.browser.msie == true) {
    var target = url + "userName" + userName;
    target = url.replace(/\.|\?|\&|\/|\=|\:|\-|\s/gi,"");
}

But target variable appended with userName is not used afterwards, the final value of target variable does not include the parameter.

I’ll bet the developer intended to write target = target.replace but he made a mistake. To avoid this kind of mistake, double check when you are not using a variable that is assigned a value.

Unused variable case like the above is not specific to JavaScript, but the following uninitialized case is so.

In Modernizr, you can see an incorrect use of uninitialized variable html5: /src/html5shiv.js

You can see html5 variable declaration at line 7. It’s here because a developer wanted “Take the html5 variable out of the html5shiv scope so we can return it”.

But, 2 years later, another developer made a commit adding var at line 23. As a result, html5 variable returned at line 38 has undefined value.

If you are Java developer, the compiler will complain this “Uninitialized variable” but JavaScript developer can’t get such help. That’s why I developed this rule for checking the use of uninitialized variable.

4. Use of constant condition

Check your code again if you are using constant or redundant checks in conditional statements.

null/undefined

In Apache Ambari, let’s see an argument check: app/utils/number_utils.js

Condition str==undefined is always false because of the previous condition str==null. Note that undefined equals to null by non-strict equality operator ==. The condition is completely unnecessary.

Also when I review code, I often see argument check code like:

if (arg == null || arg == undefined || arg == '')

You can just do dead simple because == operator in JavaScript treats equally null, undefined and empty string ''.

if (!arg)

Nested if

In Apache Ambari, let’s see an argument check: app/controllers/main/host/bulk_operations_controller.js

turn_off at line 12 is always false because it’s in false branch of the condition at line 5. Therefore line 13 is never executed and included_hosts parameter is never set.

Similar problem can be found in Adobe Brackets: src/extensions/default/UrlCodeHints/main.js

self.cachedHints at line 11 is null because it’s checked by the condition if (this.cachedHints) at line 3. So line 12 is never executed and it implies you need to check the logic for rejection. Whether the rejection was unnecessary or processed at the wrong branch.

As a rule of thumb, check the logic again when you see constant condition and remove it if it turns out to be unnecessary.

5. Inconsistent null checks

Check for null arguments should be performed consistently.

Let’s see an inconsistent example in reveal.js: plugin/markdown/markdown.js

• At line 3, argument element is checked whether it is null.
• At line 11, it is accessed without any check.
• It can cause TypeError when null argument is passed. The check is needed also here if the argument can be null.

Another example in Apache Ambari: app/mixins/common/serverValidator.js

• At first, argument data is checked and a warning is printed.
• But flow does not stop!
• Falsy value is saved as recommended at line 5.
• Finally, TypeError is thrown when accessing resources array at line 6.

For your information, check for data argument was removed in the current code. Like this, consider the following when you check an argument:

• Remove the check itself if the argument cannot be null.
• Add checks consistently for each use.

6. Null pointer

I’ve found some cases trying to access the property of null object. It is often found in an else branch or inline initialization block. Seems that developers used up all their energy in coding the main execution flow.

Let’s see Adobe Brackets: src/language/HTMLInstrumentation.js

At line 20 (else branch), match variable is set to null. But match.mark is accessed at the end of the function, causing TypeError.

I think the fix should be return match && match.mark; and I happily found the problem is gone by this commit saying “This fixes `TypeError: Cannot read property ‘mark’ of null`”. Good job!

Another case in jQuery Mobile: demos/popup-alignment/popup.alignment.js

See align.x at line 11 (inline initialization block). Because align is uninitialized at that point, accessing align.x throws TypeError.

Seems that the desire to save one line of code caused this error. I guess the developer’s intent as follows:

    var arX = parseFloat( ar[ 0 ] );
    align = {
        x: arX,
        y: ar.length > 1 ? parseFloat( ar[ 1 ] ) : arX
    };

Null pointer is one of the major runtime errors. Therefore, if you set a variable to null or access an object in initialization block, pay attention to the way the variable is used afterwards or the object is properly initialized.

7. Misuse of return values

There are two erroneous cases about the return value of a function:

• You use a return value from the function which returns nothing
• You do not use a return value from the function which has no side effect

Let’s see the first case in CodeMirror: mode/vb/vb.js

Function dedent does not return anything. So if (dedent(stream, state)) is always false and ERRORCLASS is not returned.

When should ERRORCLASS be returned? I guess that might be when dedent returns zero or negative index. In other words, it implies that a return statement is missing in the function.

And the second case is often found when using built-in API of JavaScript string.

Below is our in-house code.

var retString = i18n.RESTOREDLG_SUCCESS + ' : ( ' + returnValue.unitServiceName + ' )';
if(returnValue.isRenamed) {
    retString.concat(' , '+i18n.RESTOREDLG_RENAME);
}
Notify.success(retString);

String.prototype.concat() always returns a new string without side effect. But the developer missed the return value of it. Therefore, users see the same notification message regardless of his action.

For the API of array, there is similar confusion. Array.prototype.concat() returns a new array without side effect while Array.prototype.push() appends an item to the input array itself.

It will be better if a tool can check these kinds of confusion rather than the problem is found after deployment. This is why I developed this rule for checking an ignored result of built-in APIs.

8. Bad operators

Next let’s see bad uses of assignment, bitwise, and negation operators.

See below negation operator in our in-house code.

if (!data instanceof Object) {

The expression is evaluated as (!data) instanceof Object, comparing boolean with Object. I bet the developer wanted !(data instanceof Object). If not, using parentheses will be helpful to indicate the rare situation.

The second is about bitwise operator. See uptime: lib/pollers/webpagetest/webPageTestPoller.js

config.webPageTest.testOptions | {} is definitely typo of config.webPageTest.testOptions || {} because bitwise operator in the former converts an object to NaN, resulting zero.

Therefore, you should check it out when the bitwise operator is used in the initialization pattern like bar | {}.

Although JSHint can prohibit the use of bitwise operator, it might be annoying because it detects all uses literally. For example, below code seems correct to me while JSHint complains.

function foo(option) {
    const OPTION_1 = 1 << 0;
    const OPTION_2 = 1 << 1;

    let isOption1 = option | OPTION_1;

For the assignment operator, let’s see MagicMirror: modules/default/alert/alert.js

At line 6, you can see an assignment operator in conditional statement. As a result, show_notification is called even when the payload type is not “notification”.

Pay attention to the assignment operator if it’s in conditional statement.

Thanks for reading!

JavaScript is easy to learn but error-prone unless a developer is extra careful.

So I wanted to share some patterns I’ve found while developing our JavaScript static analysis tool, DeepScan. I hope being aware of these patterns will be helpful to developers.

Tell me if you have an idea for the pattern to be checked in JavaScript. We will realize and spread that idea!

You can find me here:

• Official Website: https://deepscan.io
• Email: support@deepscan.io

Case Studies for Common Pitfalls That JavaScript Developers Should Know was originally published in DeepScan on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the previous post I discussed the following mistake patterns of React with the examples from open sources.

• Typo of React API
• Incorrect return value from render()
• Invalid event handler function
• …

Today I will go into additional pitfalls. These are as follows:

• Invalid event handler of string type
• Event handler not bound with this
• Incorrect style property
• Missing key property in a React element

Let’s start part two. Before you proceed, I recommend reading the previous post.

In this article, I explain other confusing things for new React developers with the examples from open source projects.

1. Invalid event handler of string type

In HTML, an event handler is specified as a string. For example, script code inside string literal represents onclick handler like <image src="hello.png" onclick="alert('Hi')" />.

However, only function objects are allowed for React’s event handler. So when you specify an event handler as a string, React throws an exception.

In the test code of React, you can see a test for this invalid string-typed event handler.

Let’s see an example: __tests__/EventPluginHub-test.js (Line numbers are different because only relevant parts are shown.)

Note that you should not write an event handler like <div onClick="console.log('clicked')">. Right way is below:

DeepScan Rule

DeepScan’s BAD_EVENT_HANDLER rule can prevent developers from making this mistake by checking whether a string is specified as a React event handler.

2. Event handler not bound with this

Let’s look at another thing about React event handler.

Since React does not provide this object when calling an event handler, a TypeError exception is thrown when you access the property of this in the event handler.

To solve this problem, you need to do one of the following:

• Use Function.prototype.bind() to explicitly bind this with the handler
• Use an arrow function of ES6 that automatically bind this

Note that React.createClass() automatically binds member functions to this, so you need to be especially careful when converting it to a ES6 class.

In the below site-settings/form-general.jsx example from open source project wp-calypso, an error occurs because unbound this.trackUpgradeClick function is specified as an event handler.

I’m glad to see this problem is fixed by changing trackUpgradeClick as an arrow function. (Check this commit)

I think this kind of mistakes can be common especially to front-end developers not familiar with ES6.

DeepScan Rule

DeepScan’s EVENT_HANDLER_INVALID_THIS rule can prevent developers from making this mistake by checking whether an event handler function is bound to this.

You can track down the problem easily because the alarm says this is accessed in trackUpgradeClick function body.

3. Incorrect style property

Similar to the case that an event handler cannot be specified as a string, React’s style property does not accept a string that represents CSS rules.

Unlike HTML, you should always specify style property as an object. React will throw an exception when you specify a value other than an object, null, or undefined.

You can see this case in the test code of React. (__tests__/ReactDOMComponent-test.js)

DeepScan Rule

DeepScan’s BAD_STYLE_PROP rule can prevent developers from making this mistake by checking whether style property is specified as a non-object value.

4. Missing key property in a React element

When updating the DOM tree React optimizes rendering through diff algorithm utilizing key property.

So, rendering can be inefficient if each child element of a DOM node does not have a key property. Also, React warns about this situation.

Therefore, you should specify a key property when you define a child element in the collection.

Below components/home.js code from open source project react-vis has missing key property problem for the collection stored at content.

This problem was fixed in the later commit by adding a key property.

DeepScan Rule

DeepScan’s MISSING_KEY_PROP rule can prevent developers from making this mistake by checking each element in the collection for the existence of key property.

Thanks for reading!

You can check the above codes by directly pasting it on this Demo page.

I’ll continue to share what will be helpful in React and JavaScript development. If you have feedback or suggestions, you can find me here:

• Official Website: https://deepscan.io
• Email: support@deepscan.io

A few things every new React developer should know (part 2) was originally published in DeepScan on Medium, where people are continuing the conversation by highlighting and responding to this story.

My colleagues and I set out to build JavaScript static analysis tool DeepScan which aims to support React well in addition to common JavaScript errors.

We have developed dozens of React validation rules by gathering common pitfalls and feedback from React developers. Among them, I will share a few rules that new React developers are easy to make mistakes.

Let’s start part one.

React is a decent JavaScript UI library that Facebook leads the development and marketing.
It’s getting a lot of popularity with features such as component structure, state management separated from DOM, fast rendering, and JavaScript-centric implementation. But it’s also a bit difficult to front-end developers who are accustomed to direct handling of DOM and working with separate HTML.

In this article, I explain a few difficult things for new React developers with the examples from open source project wp-calypso.

1. Typo of React API

Developers often make a typo in the React component’s lifecycle method or PropTypes.

Lifecycle methods

React component has lifecycle methods that are invoked when the component is created or a state change occurs.

• componentWillMount()
• componentDidMount()
• componentWillUnmount()
• componentWillReceiveProps()
• shouldComponentUpdate()
• componentWillUpdate()
• componentDidUpdate()
• render()

But these names are a bit long and camelCased, so it’s easy to make a typo.

Let’s see an example: sync-reader-follows/index.js

import { Component } from 'react';

class SyncReaderFollows extends Component {
    check() {
        if ( this.props.shouldSync ) {
            this.props.requestFollows();
        }
    }
 
    componentDidMount() {
        this.check();
    }
 
    componentDidUpate() {
        this.check();
    }
 
    render() {
        return null;
    }
}

The developer intented to call check() in componentDidUpdate after state has changed, but it is not called because of a typo componentDidUpate.

PropTypes

React’s PropTypes allows to specify the types of properties (whether they are required, the type of values, etc.) that a component has.

import React from 'react';
import PropTypes from 'prop-types';

export default class Item extends React.Component {
    static propTypes = {
        id: PropTypes.number.isRequired,
        comment: PropTypes.string,
    }
}

PropTypes is defined as camelCased propTypes (see above), but developers sometimes use it as PropTypes (see below example google-plus-share-preview/index.js).

import React, { PureComponent, PropTypes } from 'react';
import { localize } from 'i18n-calypso';
import { truncateArticleContent } from '../helpers';

export class GooglePlusSharePreview extends PureComponent {
    static PropTypes = {
        articleUrl: PropTypes.string,
        externalProfilePicture: PropTypes.string,
        externalProfileUrl: PropTypes.string,
        externalName: PropTypes.string,
        imageUrl: PropTypes.string,
        message: PropTypes.string,
    };
}

PropTypes check for GooglePlusSharePreview component is not performed because of a typo PropTypes.

DeepScan Rule

DeepScan’s REACT_API_TYPO rule can prevent developers from making this mistake by finding these typos. Also, developers can easily fix the code by using the suggested method name.

2. Incorrect return value from render()

React’s render function returns a DOM tree (React element) to display in the UI. When there is no information to display, it can return null or false. An error occurs if any other value is returned.

Let’s see an example: plugin-site-update-indicator/index.jsx

var React = require( 'react' );

module.exports = React.createClass( {
    render: function() {
        if ( ! this.props.site || ! this.props.plugin ) {
            return;
        }
        if ( this.props.site.canUpdateFiles &&
                ( ( this.props.site.plugin.update && ! this.props.site.plugin.update.recentlyUpdated ) || this.isUpdating() ) ) {
            if ( ! this.props.expanded ) {
                /* eslint-disable wpcalypso/jsx-gridicon-size */
                return <Gridicon icon="sync" size={ 20 } />;
                /* eslint-enable wpcalypso/jsx-gridicon-size */
            }
     
            return this.renderUpdate();
        }
        return null;
    }
} );

The developer would have checked props and returned immediately because there is nothing to display.

However, render function of React can only return React element, null, and false. So when undefined is returned, an exception will be thrown and lifecycle methods to be executed after the rendering will not be invoked.

It’s easy to get confused, right?

DeepScan Rule

DeepScan’s BAD_RENDER_RETURN_VALUE rule can prevent developers from making this mistake by checking the return value of render() and suggesting the proper values.

3. Invalid event handler function

Event handler in React should be a function object, but a developer might make a mistake to use an invalid one.

Let’s see an example: edit-team-member-form/index.jsx

import React, { Component } from 'react';

const EditUserForm = React.createClass( {
    recordFieldFocus( fieldId ) {
        analytics.ga.recordEvent( 'People', 'Focused on field on User Edit', 'Field', fieldId );
    },

    handleChange( event ) {
        this.setState( {
            [ event.target.name ]: event.target.value
        } );
    },

    renderField( fieldId ) {
        let returnField = null;
        switch ( fieldId ) {
            case 'roles':
                returnField = (
                    <RoleSelect
                        id="roles"
                        name="roles"
                        key="roles"
                        siteId={ this.props.siteId }
                        value={ this.state.roles }
                        onChange={ this.handleChange }
                        onFocus={ this.recordFieldFocus( 'roles' ) }
                    />
                );
                break;
        }
    }
} );

You need to assign a function as onFocus event handler.

But the result of calling recordFieldFocus() which does not have return statement comes to be undefined. As a result, event handler is not specified correctly and Google Analytics will not track the focus events.

In this case, you can fix the problem as follows:

ES5 bind function:

onFocus={ this.recordFieldFocus.bind( this, 'roles' ) }

ES6 arrow function:

onFocus={ () => this.recordFieldFocus( 'roles' ) }

However, since the above approaches create a new function for each render, there can be a performance issue. It is recommended to bind the handler once in the constructor or use separate component.

DeepScan Rule

DeepScan’s MISSING_RETURN_VALUE rule can prevent developers from making this mistake by checking the return value of a function. Since the message tells the location of the event handler function, the developer can immediately check the function causing the problem.

4. Incorrect property in DOM element

React’s DOM element uses camelCased property names apart from the existing DOM property and attribute names.

Two typical examples are:

• React requires you to use className to specify the class
• React’s click event handler is onClick than onclick. It seems to be particularly confusing to existing frontend developers who are familiar with HTML that is case insensitive.

Let’s see an example: importer/error-pane.js

import React, { PropTypes } from 'react';

export default React.createClass( {
    getImportError: function() {
        return this.translate(
            '%(errorDescription)sTry again or contact support.', {
                args: {
                    errorDescription: this.props.description
                },
                components: {
                    a: <a href="#" onclick={ this.retryImport }/>,
                    br: <br />,
                    cs: <a href="#" onclick={ this.contactSupport } />
                }
            }
        );
    }
} );

In the above code, click event handler will not be executed.

In the open source project react-native-macos, we can find an error that uses frameborder property instead of correct frameBorder property.

var React = require('React');

var Modal = React.createClass({
  render: function() {
    return (
      <div>
        <div className="modal">
          <div className="modal-content">
            <button className="modal-button-close">×</button>
            <div className="center">
              <iframe className="simulator" src={url} width="256" height="550" frameborder="0" scrolling="no"></iframe>
              <p>Powered by <a target="_blank" href="https://appetize.io">appetize.io</a></p>
            </div>
          </div>
        </div>
        <div className="modal-backdrop" />
      </div>
    );
  }
});

DeepScan Rule

DeepScan’s BAD_UNKNOWN_PROP rule can prevent developers from making this mistake by checking the property name and providing the proper one.

5. Direct use of the return value from render()

You might use the ReactComponent instance returned by the ReactDOM.render function.

This is not recommended because rendering can happen asynchronously in the future version of React and the ReactComponent instance might not be available as the return value.

In the open source project react-starter-kit below, the return value of render function is used but this value may be undefined. So a desired initialization may not be executed.

Let’s see an example: src/client.js

import ReactDOM from 'react-dom';

let appInstance;

async function onLocationChange(location, action) {
    appInstance = ReactDOM.render(
      <App context={context}>{route.component}</App>,
      container,
      () => onRenderComplete(route, location),
    );
}

if (appInstance) {
  // Force-update the whole tree, including components that refuse to update
  deepForceUpdate(appInstance);
}

In this case you need to get the instance through the ref callback function.

function cb(instance) {
}

async function onLocationChange(location, action) {
    ReactDOM.render(
      <App context={context} ref={cb}>{route.component}</App>,
      container,
      () => onRenderComplete(route, location),
    );
}

DeepScan Rule

DeepScan’s ASYNC_RENDER_RETURN_VALUE rule can prevent developers from making this mistake by checking the direct use of return value from render().

6. Invalid stopping of an event propagation

In HTML, event propagation and default behavior will be aborted when the event handler function returns false.

However, React uses a separate event system and you must explicitly call stopPropagation() or preventDefault() on the React event object to stop event propagation or prevent the default behavior.

In the open source project browser-laptop below, onMaximizeClick event handler uses the old-fashioned way returning false. So event propagation is not stopped.

Let’s see an example: navigation/windowCaptionButtons.js

const React = require('react')

class WindowCaptionButtons extends ImmutableComponent {
  onMaximizeClick (e) {
    if (isFullScreen()) {
      // If full screen, toggle full screen status and restore window (make smaller)
      windowActions.shouldExitFullScreen(getCurrentWindowId())
      if (isMaximized()) windowActions.shouldUnmaximize(getCurrentWindowId())
      return false
    }
    return (!isMaximized()) ? windowActions.shouldMaximize(getCurrentWindowId()) : windowActions.shouldUnmaximize(getCurrentWindowId())
  }

  render () {
    const props = { tabIndex: -1 }

    return <div>
      <div className='container'>
        <button
          {...props}
          onClick={this.onMaximizeClick}
          title={locale.translation(this.maximizeTitle)}>
        </button>
      </div>
    </div>
  }
}

DeepScan Rule

DeepScan’s BAD_EVENT_HANDLER_RETURN_FALSE rule can prevent developers from making this mistake by checking whether false is returned from an event handler.

7. JavaScript comment in JSX

In JSX, developers should attend to using JavaScript comments such as // or /* */.

If the comment is recognized as a text node of a component, it will be visible on the browser screen. A comment should be enclosed in curly braces like {/* */}.

In open source project belle, the comment itself is displayed. Oops!

Let’s see an example: components/RatingPlayground.js

import React from 'react';

export default React.createClass({
  render() {
    return (
      <div>
        <h2>Rating</h2>

        <Card>

          <Button onClick={ this._updateRatingToThree }>Update Rating to value 3</Button>

          //onUpdate should not be called for valueLink
          <h3>ValueLink</h3>

        </Card>

      </div>
    );
  }
});

In this case, write as the following:

{/* onUpdate should not be called for valueLink */}
<h3>ValueLink</h3>

In the opposite, when you really need “//” literally like <h3>// a is a double slash.</h3>, it is good to write like <h3>{"// is a double slash."}</h3> for clarity.

DeepScan Rule

DeepScan’s BAD_JSX_COMMENT rule can prevent developers from making this mistake by checking JavaScript comments in JSX.

8. Checking length property directly

A child element as undefined, null, true or false is not rendered. Therefore, developers use JSX expression like cond && <div>…</div> when they want to render something selectively.

However, this is not applied for the numeric value 0. For example, if array is empty in array.length && <div>…</div>, 0 is displayed on the screen.

In this case, consider the following:

• Use comparison expression explicitly like array.length > 0
• Add an empty string as OR condition like array.length && <div>…</div> || ''

The open source project react-native-macos below checks length property directly, so 0 will be displayed when this.props.params is empty.

Let’s see an example: layout/AutodocsLayout.js

var React = require('React');

var Method = React.createClass({
  render: function() {
    return (
      <div className="prop">
        <Header level={4} className="methodTitle" toSlug={this.props.name}>
          {this.props.modifiers && this.props.modifiers.length && <span className="methodType">
            {this.props.modifiers.join(' ') + ' '}
          </span> || ''}
          {this.props.name}
          <span className="methodType">
            ({this.props.params && this.props.params.length && this.props.params
              .map((param) => {
                var res = param.name;
                res += param.optional ? '?' : '';
                return res;
              })
              .join(', ')})
              {this.props.returns && ': ' + this.renderTypehint(this.props.returns.type)}
          </span>
        </Header>
      </div>
    );
  }
});

I’m just glad to see a mindful developer fixed a problem by appending || '' condition. (Check this commit)

DeepScan Rule

DeepScan’s BAD_LENGTH_CHECK rule can prevent developers from making this mistake by checking the direct use of length property.

Thanks for reading!

You can check the above codes by directly pasting it on this Demo page.

I’ll continue to share what will be helpful in React development. If you have feedback or suggestions, you can find me here:

• Official Website: https://deepscan.io
• Email: support@deepscan.io

Resources

Check out additional starting resources for React:

• React Tutorial: How to Get Started and How it Compares

A few things every new React developer should know (part 1) was originally published in DeepScan on Medium, where people are continuing the conversation by highlighting and responding to this story.