Hacker News new | comments | show | ask | jobs | submit login
Great React style guide by Airbnb (github.com)
50 points by owens99 5 months ago | hide | past | web | favorite | 19 comments



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.


> 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.


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.


We are doing this as well and I agree that there are a number of nice things about it. I find that the closer to HTML my code is, the more I prefer JSX whereas if I am using mostly components, it starts to feel silly.

In addition to your points, a nice thing about pure JS is that you can optionally add an element with a simple ? operator without having to "break" things with curly brackets. createElement excepts null/undefined as something it will just skip.


For 6, you can have each attribute on its own line when you have more than 1. Makes vertical split a breeze to use :)


Took me a while to get used to but now I prefer HTML this way too. It makes it really easy to understand what's happening at a glance.


>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.


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.


VSCode makes this a little easier. It's pretty good at suggesting index.jsx if you search for "ComponentName".


> 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.


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.


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'}
   />


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.


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.


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


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


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).

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.


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


> 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?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: