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.
// connect() is a function that injects Redux-related props into your component. | |
// You can inject data and callbacks that change that data by dispatching actions. | |
function connect(mapStateToProps, mapDispatchToProps) { | |
// It lets us inject component as the last step so people can use it as a decorator. | |
// Generally you don't need to worry about it. | |
return function (WrappedComponent) { | |
// It returns a component | |
return class extends React.Component { | |
render() { | |
return ( |
import React, { Component } from 'react' | |
import { SubWidgetLink } from './routes' | |
export default class MyComponentWithALink extends Component { | |
render() { | |
const { widget } = this.props | |
return ( | |
<div> | |
... |
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
[02:06 PM] acemarke: @Steven : a couple other thoughts on the whole NODE_ENV
thing. First, per my comments, it really is a Node concept. It's a system environment variable that Node exposes to your application, and apparently the Express web server library popularized using its value to determine whether to do optimizations or not
[02:08 PM] acemarke: Second, because of its use within the Node ecosystem, web-focused libraries also started using it to determine whether to they were being run in a "development" environment vs a "production" environment, with corresponding optimizations. For example, React uses that as the equivalent of a C #ifdef
to act as conditional checking for debug logging and perf tracking. If process.env.NODE_ENV
is set to "production"
, all those if
clauses will evaluate to false
.
Third, in conjunction with a tool like UglifyJS that does minification and removal of dead code blocks, a clause that is surrounded with if(process.env.NODE_ENV !== "development")
// getComponent is a function that returns a promise for a component | |
// It will not be called until the first mount | |
function asyncComponent(getComponent) { | |
return class AsyncComponent extends React.Component { | |
static Component = null; | |
state = { Component: AsyncComponent.Component }; | |
componentWillMount() { | |
if (!this.state.Component) { | |
getComponent().then(Component => { |
A top-level App
component returns <Button />
from its render()
method.
What is the relationship between <Button />
and this
in that Button
’s render()
?
Does rendering <Button><Icon /></Button>
guarantee that an Icon
mounts?
Can the App
change anything in the Button
output? What and how?
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
class Action { | |
private String type; | |
private Object data; | |
public Action(String type, Object data) { | |
this.type = type; | |
this.data = data; | |
} | |
public String getType() { |