Great React style guide by Airbnb
github.com
github.com
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.
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.
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.
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.
You can still import it as `./ComponentName` as you would with having `index.jsx` inside the folder. Best of both worlds, IMO.
I am deeply offended. I've always suspected double-quote people had some issues but using both is unforgivable.
EDIT: The more I think about it the more wrong it feels. Would you do something like this?
<Foo
bar="bar"
baz={qux && 'biz'}
/>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.
I think it's silly to add another rule to remember with such a weak justification.
See here: https://github.com/yannickcr/eslint-plugin-react/issues/412
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.
Why not do it right in the body of the class with an arrow function?