The from...import section of the Python style guide says:

Rationale: This is the single best -- and easiest -- way to avoid the circular-import problem. To simplify, when you say import x, Python executes the x.py file, but doesn't need to get any attributes from it. When you say from x import foo, Python needs x.py to be executed enough that foo is defined in it. When x does a 'from-import' from y, and y does a 'from-import' from x, the circular import can succeed if a partial module is enough (as it will be with import x), but it can fail if the circularity happens before the needed attribute is defined (as it might be with from x import foo).

I had trouble proving this to myself with manual testing; I think this section could really benefit from a link to some concrete example code that showcases a successful example of this behavior.

Just wondering. I am used to next.js, which has a getInitialProps function to AJAX on server render.

Trying to write best practices at our company, so just wanted that clarification.

• replace propTypes with props: <Props>
• how to type children properly, e.g. string | React$Element<any> | React$Element<any>[]
• describe order that we current lint against

disregard - closing

A link, (example) is bad here

• remove sorting of require/import statements
• blocks continues to be the same with the addition of a new block, flow type imports which should come last
• prefer ES6 import syntax over require
• destructuring should happen on the same line as the import, e.g. import React, {Component} from 'react'

The preferred ternary style is the following:

• if it can fit on a single line, put it on a single line, e.g. const color = selected ? 'green' : 'orange'
• if it can't fit on a single line, put the ? and : at the start of each line, e.g.

const result = reallyVeryLengthConditional
    ? superLongComputationOfPositiveResult()
    : superLongComputationOfNegativeResult();

const style = selected
    ? {
        color: 'green',
        fontWeight: 'bold',
    }
    : {
        color: 'orange',
    }

Hey, I noticed a broken link at line 171 of the document in section.

Document: https://github.com/Khan/style-guides/blob/master/style/react.md

Broken URL :
https://github.com/Khan/webapp/blob/32aa862769d4e93c477dc0ee0388816056252c4a/javascript/search-package/search-results-list.jsx#L14

Sorry for the rapid fire comments, needed to get it out before jumping into a meeting and forgetting.
Continuing the feedback from #28.

There are a couple of methods that are sufficiently complicated and don't have a direct equivalent so instead we have a custom-built copy of lodash containing only those specific methods. You can find this file at: third_party/javascript-khansrc/lodash/lodash.js along with instructions on how to build it and exactly what methods are included.

In addition, Lodash is totally modular & works great with browserify / webpack to create smaller bundles. There's even a babel plugin to avoid mucking with module paths.

var cloneDeep = require('lodash.clonedeep');
// or
var cloneDeep = require('lodash/lang/cloneDeep');

Object.assign(json, this.model.toJSON()) | _.extend(json, this.model.toJSON())

It would be better to compare to _.assign as that's closer to Object.assign
(iterating only own properties of source values instead of own+inherited in _.extend).

for (const [key, val] of Object.entries(obj)) {} | _.each(obj, fn)

In Lodash there's _.forOwn and _.forIn for object iteration too

defer | setTimeout(fn, 0); | _.defer(fn);
delay | setTimeout(fn, 2000); | _.delay(fn, 2000);

The useful bit for _.defer and _.delay is they allow partially applying arguments to the deferred/delayed function, which older environments lacked in setTimeout (may be worth noting).

bindAll | `obj.method = obj.method.bind(someObj);

Typo, fix to obj.method = obj.method.bind(obj);

once

{
    method: () => {
        if (this._initDone) { return; }
        this._initDone = true;
        ...
}

This will assign _initDone to the outer this so not really appropriate for per method state.

That way everything regarding styles/best practices in the same place.

I believe it's safe to say, after the internal vote, that people prefer:

import React, {Component} from "react";

class Thing extends Component { ... }

over

import React from "react";

class Thing extends React.Component { ... }

The examples in react.md all use the React.Component style, so we should update them to just extend Component. We can also add a blurb about the import convention?

cc @kevinbarabash