Eliminate all promises from application.
The Promise API is the source of many confusing errors in our application, using node style callbacks eliminates the issue without reducing code quality.
import { connect } from 'react-redux' | |
import ProfilePicture from 'components/ProfilePicture' | |
import { changeProfilePicture } from '../actions' | |
export function mapStateToProps(state:any, ownProps:any):any | |
{ | |
return { | |
profilePictureUrl: state.user.profilePictureUrl, | |
} | |
} |
Build our UI framework inside a monorepo using Lerna.
Building npm packages across many individual repos make big changes difficult to make, test, and publish. Using a monorepo we can solve many of these and
const store = createStore((state = { counter: 0 }, action) => { | |
switch(action.type) { | |
case "INCREMENT": | |
return { counter: state.counter + 1 } | |
case "DECREMENT": | |
return { counter: state.counter - 1 } | |
default: | |
return state | |
} | |
}) |
//////////////////////////////////////////////////////////////////////// | |
// Intro | |
/////////////////////// | |
// Tools like Redux-saga, React-redux and Reselect can easily be used without Redux | |
// For Reselet there's nothing to do, it's just not coupled to Redux | |
// For the others, you just need to provide an adapter | |
// At Stample.co we use a legacy framework that is quite close to Redux but with a bad API | |
// We want to progressively migrate to Redux, so starting now to use Redux tools on new features will make our migration faster |
import React, { Component } from 'react' | |
import Subapp from './subapp/Root' | |
class BigApp extends Component { | |
render() { | |
return ( | |
<div> | |
<Subapp /> | |
<Subapp /> | |
<Subapp /> |
[...document.querySelectorAll('.invite-card')].forEach(card => { | |
const headline = card.querySelector('.headline').textContent; | |
const accept = card.querySelector('.bt-invite-accept'); | |
const decline = card.querySelector('.bt-invite-decline'); | |
const name = card.querySelector('.name').textContent; | |
if(headline.match(/recruit/gi)) { | |
console.log(`Nah. ${name} looks a little fishy to me. 🚷🚷🚷`); | |
decline.click(); | |
} else { |
import { Component } from "React"; | |
export var Enhance = ComposedComponent => class extends Component { | |
constructor() { | |
this.state = { data: null }; | |
} | |
componentDidMount() { | |
this.setState({ data: 'Hello' }); | |
} | |
render() { |
function mapValues(obj, fn) { | |
return Object.keys(obj).reduce((result, key) => { | |
result[key] = fn(obj[key], key); | |
return result; | |
}, {}); | |
} | |
function pick(obj, fn) { | |
return Object.keys(obj).reduce((result, key) => { | |
if (fn(obj[key])) { |
Article by Faruk Ateş, [originally on KuraFire.net][original] which is currently down
One of the most commonly overlooked and under-refined elements of a website is its pagination controls. In many cases, these are treated as an afterthought. I rarely come across a website that has decent pagination, and it always makes me wonder why so few manage to get it right. After all, I'd say that pagination is pretty easy to get right. Alas, that doesn't seem the case, so after encouragement from Chris Messina on Flickr I decided to write my Pagination 101, hopefully it'll give you some clues as to what makes good pagination.
Before going into analyzing good and bad pagination, I want to explain just what I consider to be pagination: Pagination is any kind of control system that lets the user browse through pages of search results, archives, or any other kind of continued content. Search results are the o