Add initial React guidelines. #2
Conversation
| ## Write Focused Components | ||
| Like functions, well-designed React components should focus on a specific piece of functionality. Prefer factoring code into many small, focused components over monolithic components that cover major feature areas. Most apps tend to have a few large components that pull together several unrelated features. These should be rare, and in cases where they're needed prefer composing many smaller components rather than implementing functionality directly within the monolithic component. | ||
|
|
||
| Small and focused components are easier to read and understand. They're also easier to reuse if the need arrises, and they provide React with optimization opportunities because you can easily use `React.memo` to avoid unnecessary re-renders. |
There was a problem hiding this comment.
Nit: "arrises" -> "arises".
(I wonder how practical it would be to have a "build" for this repo that just runs a spellchecker…)
There was a problem hiding this comment.
Thanks. I should really use a spellchecker in markdown documents…
sections/react.md
Outdated
|
|
||
| Many of React's exports use overly generic names, or shadow globals. e.g., `Component`, `lazy`, `MouseEvent`. Using named imports for these makes code harder to read because additional context is required to understand that these are React APIs. Hooks get an exception because they use a very specific naming convention that's unlikely to conflict, and function components are easier to read when built-in hooks don't get special treatment over custom hooks. | ||
|
|
||
| We write a lot of React code, and consumign the React API in a consistent way makes code easier to read, and team transitions smoother. |
| import * as React from 'react'; | ||
|
|
||
| // bad | ||
| import React, { Component, TouchEvent, useEffect } from 'react'; |
There was a problem hiding this comment.
This is sufficiently easy to describe that it should be an eslint rule.
There was a problem hiding this comment.
Agree. I think there are a few we could add rules for.
| Sometimes SVGs include `id`s. If possible, ask design for an alternate implementation. If `id`s are required, use a tool or webpack plugin to ensure they are unique in the project. | ||
|
|
||
| ## Use Focus to Dismiss Modals | ||
| Generally, the easiest way to dismiss a modal dialog or menu is with an "outer click" pattern. When the modal opens, you add a `click` event listener to body, and check if you see any clicks outside the modal, you close it. This is fundamentally broken for keyboard users, who will get stuck in dialogs they cannot dismiss. The correct way to dismiss a modal is to track focus, and close the modal when focus moves outside the modal container. It's more work, but it results in a far better user experience. |
There was a problem hiding this comment.
I don't recall specifics, but I'm pretty sure I've encountered instances in which this approach created some cross-browser nightmares, particularly with modals hosting fully custom UI components (maybe a calendar picker?)
There was a problem hiding this comment.
It's definitely harder to manage, and React doesn't help you out a lot. I hope we have better solutions to focus management in the future.
Related: reactjs/rfcs#109
No description provided.