Reach UI is an accessible foundation for React applications and design systems.
The three equally important goals are to be:
- Accessible
- Composable
- Stylable
export class UserList extends React.Component { | |
state = { count: 0 }; | |
handleClick = (item) => { | |
setTimeout(() => { | |
console.log(`You clicked ${this.props.group} ${this.state.count} times`); | |
}, 3000); | |
}; | |
render() { |
const addEventing = function (obj) { | |
let events = {} | |
obj.on = (eventName, fn) => { | |
if (events[eventName]) { | |
events[eventName].push(fn) | |
} else { | |
events[eventName] = [fn] | |
} | |
} |
Back in 2010, Vincent Driessen wrote a post called
A successful Git branching model.
Besides being extremely well drafted and clear in it's intention, the post goes
into great detail about Git branching strategies and release management. The
model that Vincent (sobriquet "nvie") came up with was popularized as git-flow
.
The following links were used as references for this talk: SF RoR Meetup: High Performance Learning
I've been using controlled components for near everything in my application as that has been the recommended way to go, and I subscribe to the idea that React should be in control of this state when possible.
However, I recently went through @ryanflorence's Advanced React course—which is a wonderful collection and breakdown of some powerful (and still uncommon) patterns available in React—and the last lecture is on controlled components.
At around 17:40 in the lecture video, Ryan does something very interesting. He writes some code that looks like this:
<Tabs
defaultActiveIndex={this.state.currentTab}
onChange={(index) => {
const rawCategories = { | |
'hierarchical_categories.level_1': { | |
'Beverages': 349, | |
'Coffee & Tea': 4, | |
'Deli': 35 | |
}, | |
'hierarchical_categories.level_2': { | |
'Beverages > Energy & Sports Drinks': 54, | |
'Beverages > Juice & Nectars': 111, | |
'Deli > Cheeses': 30 |
import React, { Component } from 'react' | |
import api from './api' | |
class App extends Component { | |
constructor () { | |
super() | |
this.state = { | |
name: null, | |
imgUrl: null | |
} |
Decorators are used to add new functionality to an already existing object by "wrapping" it with new methods, without effecting other instances of that object. Thus, decorators are a perfect example of the Open/closed principle, in which an object is "open for extension" but "closed for modification"; you should be able to add new behavior to application without changing it's underlying source code. If any of this is a bit hard to swallow, I would