-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Advanced React #1
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Note: I deliberately leave many of the topics below out of fundamentals.
React top level api: https://reactjs.org/docs/react-api.html
Upcoming "use" hook
Primitive for handling asynchrony.
Works like “await” inside non-async client-side components.
Wrap promises (and soon other things like context) with “use”.
If a promise passed to use isn’t resolved, “use” suspends the component’s execution by throwing an exception. The component replays when the promise resolves.
A “usable” type is a wrapper for a value. Calling “use” unwraps it.
Only for client (like most hooks).
Async server components use plain async/await.
Only non-async server components can use hooks.
Unlike other hooks, can be called conditionally. Why? Because the data lives in the promise object itself. So there’s no need to store state for “use” across updates.
Can be placed in the same spots as “await” including blocks, switch statements, and loops.
Part of the “Data fetching with Suspense” story.
UI Architect / Frontend Architect / FrontendOps /ops - Responsibilities:
State management / Finite State Machines / Statecharts
Reusable components, scripts, styles
Design system / Style Guide (collaboration)
Dev environment (transpiling/bundling/linting...) and dev tools
Build automation
Mock APIs
Automated testing (unit/integration/visual)
App composition/slicing
Error handling
Event Modeling
Accessibility
Performance
Security
Dev tools
Dependency management
More here and here
Signs it's time to consider extracting a new component
Why prefer fewer components?
So it's a tradeoff.
Useful middle ground here: You can declare multiple components in a single file, but export only the "parent". This avoids jumping between files and provides a clear public API. If you prefer separate files, you can create a component folder and place all its child components in that folder, then use a barrel to export only the Header.
Brain Teaser
Why doesn't the onSubmit fire here?
Patterns for scaling
Capture
to event name.onClickCapture
,onHoverCapture
, etc. ExampleUseful for large apps, multiple apps in the org, or cross-cutting concerns
Advanced Hooks
React.memo
,shouldComponentUpdate
, orPureComponent
to avoid re-renders benefit from having a parent that uses useCallback to avoid needlessly sending down a new func reference on each render.Example Custom Hooks
numApiCallsInProgress
or an array ofapiCallsInProgress
with an identifier for each between hooks via context.JSX in Depth
Layout
component - This can hold your header, footer, context provider(s), scenario selector.Key Advanced Features
Context
Refs
useCallback
with a ref to run some logic when the ref's target changes. useCallbackRef example)myRef.current = 'val here'
.current
property:myRef.current
Other Advanced Features
State
useState
by passing it a func. Then the initial value isn't calculated only on initial render. (Plain default values are executed on page load when the component is parsed).Props
{React.isValidElement(heading) ? heading : <H1>{heading}</H1>}
const { roleId, locks, ...passThroughProps} = props;
Performance
Old alternatives to React.lazy:
this
keywordevent.target.elements.fieldName.value
- See SearchInput here. Or extract child components to avoid bindingForms
I recommend plain React. Here's a poll. But, many options. A few popular options:
Maintainability
import UserList from './User/List.js';
Debugging
Server Rendering
Deployment
More?
The text was updated successfully, but these errors were encountered: