import { Appear, Image } from 'mdx-deck'; import { Split } from 'mdx-deck/layouts'; import { CodeSurfer } from 'mdx-deck-code-surfer'; import codeSurferTheme from './src/monokai-theme'; import QuoteLayout from './src/quote-layout' import Layout from './src/layout'; import LayoutNoFooter from './src/layout-no-footer'; import LayoutCenter from './src/layout-center'; import UnitOfWork from './src/unit-of-work'; import Diagram from './src/diagram'; import TargetLogo from './src/target-logo'; import { BlockHeader, BorderedText, H2 } from './src/headers'; import { ImpressionsManager, IncrementImpressions, ImpressionsCounter } from './src/impression-tracker.js';
export { default as theme } from './src/theme'
export default LayoutNoFooter
Units of Work
export default LayoutNoFooter
Engineer at Target
@brkalow
I work on target.com's React front-end
Let's talk about components...
export default QuoteLayout
Components let you split the UI into independent, reusable pieces, and think about each piece in isolation.
In their purest form, components represent individual pieces of our UIs
export default Layout
- Fetch data
- Add event listeners
- Handle navigation
- Manage state
- Transform data
- Set timers
- Control focus
- Track user interactions
- Inject scripts
- Handle scrolling
As our applications grow, our components also evolve to encompass a lot of other functionality
It can get pretty overwhelming!
export default Layout
We use the React lifecycle to control the execution flow of our applications in between renders
This is crucial for large React applications, as most things are dictated by and revolve around
the React component tree. Navigation, app state, and configuration are often all orchestrated by
some piece of React.
export default Layout
How can we orchestrate functionality within the React lifecycle without constructing brittle, hard-to-maintain logic?
* Similar logic in DidMount and DidUpdate
* Think about comparing props in DidUpdate to get that condition exactly right
export default LayoutCenter
export default Layout
but they can still do something
Returning null from render is totally valid, you might even be using this pattern without realizing it.
export default Layout
It's a simple pattern, but I think it is also really powerful
export default LayoutCenter
We can take logic spread across mulitple lifecycle methods and put them into components,
then use these components to compose logic, just like we do for our UI
export default Layout
// use keys to trigger execution
<RetainScrollPosition key={url} />
// declare application flow
if (!loggedIn) return <Redirect to={loginPage} />;
We can do cool things like...
* use keys to trigger execution
* define how our application should function in a declarative way
export default LayoutNoFooter
<CodeSurfer title="" code={require("!raw-loader!./src/client-version-check.js")} theme={codeSurferTheme} lang="javascript" showNumbers={false} dark={false} steps={[ { lines: [7,8,9] }, { lines: [23,24] }, { lines: [28] } ]} />
export default Layout
import { Route, Redirect } from 'react-router'
<Route exact path="/" render={() => (
loggedIn ? (
<Redirect to="/dashboard"/>
) : (
<PublicHomePage/>
)
)}/>
`react-router` uses this pattern quite a bit, they have a renderless component in their source called `<Lifecycle>`.
From: https://reacttraining.com/react-router/web/api/Redirect
export default Layout
Think in React
The React docs have a great page on "thinking in React", and I believe that this pattern is
just a continuation of that idea.
export default Layout
https://components-units-of-work.now.sh
If you're using this pattern, or just want to talk about anything React, come find me!
Thank you, enjoy the rest of conference.