Writing modern SPA applications
part 3: REACT.JS
different approaches for
rendering ui
Render once, then bind events and modify dom
rerender entire component on state change
virtual dom
virtual dom
virtual dom
- faster than always updating and then rerendering and repainting DOM (which is slow)
- does not require rebinding of events (which is slow)
- optimizied with simple heuristic to make tree comparison as fast as possible
- make UI changes predictable and trackable
component based
application design
traditional mvc architecture
component-based architecture
what exactly is this
component
component structure
component lifecycle
wait a minute
how children work
JSX UNDER THE HOOD
const foo = (
<div className="button">
<button type="submit"/>
</div>
)
// this gets transpiled to
const foo = (
React.createElement("div", {
className: "button"
children: [
React.createElement("button", { type: "submit" })
]
})
)
components can be
objects
react.component
import React, { Component } from 'react'
import { Link } from 'react-router-dom'
class Dropdown extends Component {
onToggle() {
this.setState({ visible: !this.state.visible })
}
render() {
return (
<div className="dropdown">
<button className="dropdown__button" onClick={this.onToggle}>
Menu
</button>
{this.state.visible &&
<div className="dropdown__content">
<Link to="/">Home</Link>
<Link to="/about">About</Link>
<Link to="/pricing">Pricing</Link>
</div>}
</div>
)
}
}
components can be
functions
stateless component
import React from 'react'
const Button = function Button({ type, ...props }) {
const className = type === 'white' ? 'button__white' : 'button__black'
return (
<button className={className} {...props}/>
)
}
const Input = observer(function Input({ field }) {
return (
<div className={classNames("form-group", {"has-error": field.error})}>
{field.error &&
<span className="form-group__error">{field.error}</span>}
<input className="form-control" {...field.bind()}/>
</div>
)
})
components can be
composed
higher order component
const StyledInput = function StyledInput(props) {
return (
<Input style={{ color: 'red' }} {...props}/>
)
}
// example use:
<StyledInput name="foo"/>
<StyledInput name="bar"/>
higher order component
class UserFetch extends React.Component {
componentWillMount() {
fetch('/api/users').then((users) => this.setState({ users: users }))
}
render() {
const WrappedComponent = React.Children.only(this.props.children)
if(typeof this.state.users === 'undefined') {
return <div className="loading-spinner"/>
} else {
return React.cloneElement(WrappedComponent, { users: this.state.users })
}
}
}
// example:
const UserCount = ({ users }) => <div>User count: {users.length}</div>
const Users = () => (
<div>
<UserFetch><MyComponent/></UserFetch>
</div>
)
higher order component
function withUserFetching(WrappedComponent) {
return class extends React.Component {
componentWillMount() {
fetch('/api/users').then((users) => this.setState({ users: users }))
}
render() {
if(typeof this.state.users === 'undefined') {
return <div className="loading-spinner"/>
} else {
return <WrappedComponent users={this.state.users}/>
}
}
}
}
// example:
const FetchingUserCount = withUserFetching(UserCount)
const Users = () => (
<div>
<FetchingUserCount/>
</div>
)
HOC RULES:
-
Compose instead of using inheritance to get behaviours you need
- Don't modify the original class, wrap it instead
- Pass unrelated props to underlying component when possible ({...props})
- Avoid using fat arrow syntax and use named functions instead, they show up in DevTools making them easier to spot and debug
- Do not apply HOC-making functions in render() method
HOC CAVEATS
-
Since we are composing by wrapping, static methods are not passed over and refs refer to the wrapping component, not the one underneath
- Statics can be copied manually or with hoist-non-react-statics
- To access proper refs you can pass ref callback via custom prop
const Input = function Input({ inputRef, ...props }) {
return <input ref={inputRef} {...props}/>
}
handling and passing
state and props
PASSING STATE DOWN WITH PROPS
pushing state up with callbacks
state management with
mobx
what is mobx
how does it work
mobx
- Everything in MobX works around observables. They are properties of objects for which access can be tracked.
- Tracking of access happens inside function passed to autorun (or reaction). The function is then re-run every time observable value changes.
- Actions are functions wrapped in transaction - reactions inside them are batched together an run after the function finishes.
- Computed properties are cached properties that get updated when observables used to calculate them change
mobx example
import { observable, autorun } from 'mobx'
class Store {
@observable foo = 1
}
const store = new Store
autorun(() => console.log(store.foo))
store.foo = 2 // causes console.log to be called and 2 to be printed
store.foo = 3 // ditto, 3 is printed
mobx-react
- MobX can be connected to React via observer() function
- This function wraps our component and makes it reactive.
- Reactive component is a component that rerenders automatically if any observable used to render it changes.
- @observable can replace this.state and setState completely
mobx-react
import React from 'react'
import { observable } from 'mobx'
import { observer } from 'mobx-react'
class LikeButton extends React.Component {
@observable liked = false
render() {
return (
<div>
{this.liked ? "I like this" : "I don't like this"}
<button onClick={() => this.liked = !this.liked}/>
</div>
)
}
}
export default observer(LikeButton)
data can be kept
inside stores
stores
import { observable, action, computed } from 'mobx'
class UserStore {
@observable users = []
@observable current = null
fetch() {
fetch("/api/users").then(this.setUsers)
}
@action setUsers(users) {
this.users = users
}
@computed get currentUser() {
if(this.current !== null) {
return this.users.get(this.current)
}
}
}
stores
-
Stores are source of data inside the application
- They can use Models, Repositories and other OO patterns
- Stores should be created per domain (users, projects etc)
- If relation between two entities is containment (one belongs to other), it makes sense to put them in one store
- There is always more than one way of doing things and there are many libraries that solve the problem of data storage
passing stores
using provider/inject
Provider
const userStore = new UserStore
const projectStore = new ProjectStore
const stores = { userStore, projectStore }
const App = function App() {
return (
<Provider {..stores}>
<Header/>
<Routing/>
<Footer/>
</Provider>
)
}
inject using functions
const Header = function Header({ userStore }) {
return (
<header>
{userStore.currentUser
? <div>You are not logged in</div>
: <div>You are logged in as {userStore.currentUser.name}
}
</header>
)
}
export default inject('userStore')(observer(Header))
inject using decorators
@inject('userStore')
@observer
class Footer extends React.Component {
render() {
const { userStore } = this.props
return (
<div>There are {userStore.users.length} users loaded</div>
)
}
}
time for
summary
react
- React is a component-based library, not "just a View in MVC"
- React components are re-rendered when their props or state change
- Components can be nested in each other and create a tree structure
-
Applications written in React are using composing (wrapping) instead of OO inheritance to share common functionality
- Virtual DOM is used to make sure the amount of perf-heavy operations (event binding, DOM manipulation) is minimal
mobx
- MobX is a library for making things reactive
- Core features: observable, action, computed, autorun
- MobX can be used to make React components reactive with observer(), stores can be passed with Provider/inject
- Common pattern of handling data involves creating Stores and keeping data there so they can be shared between multiple unrelated components inside application
that's it
questions?
Writing modern SPA applications part 3
By Michał Matyas
Writing modern SPA applications part 3
- 725