
Great React style guide by Airbnb - owens99
https://github.com/airbnb/javascript/blob/master/react/README.md
======
benjaminjackman
It’s interesting. I’ve switched to using ‘h’ as an alias of ‘createElement’
instead of jsx. Which breaks 2 of their top 3 rules.

I find it has a few nice advantages.

1\. It doesn’t introduce another language with different syntax that I have to
mentally flip between. Remembering stuff like surrounding variables with
curlies and using = instead of : etc.

2\. nesting thing also is much easier

3\. It’s more concise (when createElement is aliased to h)

4\. Most importantly it keeps me in the flow.

5\. It’s just another function call so additional features can be added. For
example I made a version using X instead of h that will parse the tag for
“#id.class1.class2” tokens and add them to the props as appropriate saving a
pretty decent amount of space. This is very similar to emmet so it’s nothing
out of the ordinary.

6 I think HTML looks like garbage when the number of attributes overflows the
line length. Js formats much nicer, it’s basically one token per line when it
gets that long with indenting like the rest of the file.

7\. Pulling logic out of the render call doesn’t require a as much of a code
transformation.

The biggest downside by far is that I seem to be the only one that prefers
this style from looking over lots and lots of tract libraries.

~~~
masklinn
> I’ve switched to using ‘h’ as an alias of ‘createElement’ instead of jsx.

Why just alias and not go full hyperscript?

> For example I made a version using X instead of h that will parse the tag
> for “#id.class1.class2” tokens and add them to the props as appropriate
> saving a pretty decent amount of space. This is very similar to emmet so
> it’s nothing out of the ordinary.

That reads _a lot_ like hyperscript. You really should take a look.

~~~
lewisl9029
Hyperscript looks neat, but I'm wondering if there are any other major
benefits to using it over an alias of `createElement` for someone using
component oriented styling libraries like styled-components or glamorous? i.e.
when there's no need to specify ids/classes for styling, the id/class
shorthands become less useful.

------
gabemart
>However, for root components of a directory, use index.jsx as the filename
and use the directory name as the component name

I used to do this, but I find it really confusing having dozens of files all
called "index.jsx". I eventually moved to './ComponentName/ComponentName.jsx'
in my personal projects. It's a bit more verbose, but I find it makes
everything else do to with navigating and finding files easier.

~~~
lewisl9029
Agreed that having a bunch of index.jsx files is super annoying. Though I
prefer to just create a `./ComponentName.jsx` file on the same level as the
`./ComponentName/` folder instead.

You can still import it as `./ComponentName` as you would with having
`index.jsx` inside the folder. Best of both worlds, IMO.

------
ng12
> Always use double quotes (") for JSX attributes, but single quotes (') for
> all other JS.

I am deeply offended. I've always suspected double-quote people had some
issues but using both is unforgivable.

~~~
nacs
JSX combines HTML and JS so this recommendation is basically telling you to
use double-quotes for HTML and single-quotes for JS which doesn't seem all
that crazy.

~~~
ng12
Why? It looks like HTML but it's still JS. Keep it simple.

EDIT: The more I think about it the more wrong it feels. Would you do
something like this?

    
    
       <Foo
          bar="bar"
          baz={qux && 'biz'}
       />

~~~
always_good
Yes, that example looks fair enough. One is "HTML", the other is a JS
expression. In fact, having single vs double here might help people remember
those are different contexts.

But realize you're just bikeshedding a trivial matter. All that really matters
is that everyone on the team uses the same linting rules and there is no
problem except some offended opinions about aesthetics.

It's fun to argue aesthetics but it's a waste of time.

~~~
ng12
Er, style guides deal a lot with aesthetics. That's kind of the subject matter
at hand.

I think it's silly to add another rule to remember with such a weak
justification.

------
FLGMwt
Anyone have an idea why it suggests named functions instead of arrow functions
for functional components?

~~~
wiesson
I guess debugging is easier with named functions. Arrow functions don't have
names

See here: [https://github.com/yannickcr/eslint-plugin-
react/issues/412](https://github.com/yannickcr/eslint-plugin-react/issues/412)

~~~
FLGMwt
That was roughly my guess. I asked because I ran into a specific edge case
where this is finicky.

AFAIK, arrow functions _do_ (and should) have names if they're assigned to a
variable.

    
    
      const foo = () => {};
      // undefined
      foo.name
      // "foo"
    

I ran into a specific bug where this doesn't work for the following case _when
using babel to target modern versions of node_ :

    
    
      export const foo = () => {};
    

Note that's only when the declaration is part of an export
([https://github.com/babel/babel/issues/7194](https://github.com/babel/babel/issues/7194)).

The name works fine in the browser, but since jest/enzyme use node to run
tests, I had issues with functional components (defined as arrow functions and
immediately exported) were missing their names.

FWIW, this isn't an issue in Babel 7.

------
mikewhy
be wary of "normal functions", aka "stateless functional components". They are
always re-rendered, unlike PureComponent:
[https://github.com/facebook/react/issues/5677](https://github.com/facebook/react/issues/5677)

------
hungerstrike
> Bind event handlers for the render method in the constructor.

Why not do it right in the body of the class with an arrow function?

