Some links to point people to when they misinterpret PATENTS clause or spread false claims.
https://code.facebook.com/license-faq
https://wptavern.com/automattic-will-continue-to-use-react-js-in-calypso-despite-patent-clause
Some links to point people to when they misinterpret PATENTS clause or spread false claims.
https://code.facebook.com/license-faq
https://wptavern.com/automattic-will-continue-to-use-react-js-in-calypso-despite-patent-clause
I recently had several days of extremely frustrating experiences with service workers. Here are a few things I've since learned which would have made my life much easier but which isn't particularly obvious from most of the blog posts and videos I've seen.
I'll add to this list over time – suggested additions welcome in the comments or via twitter.com/rich_harris.
Chrome 51 has some pretty wild behaviour related to console.log
in service workers. Canary doesn't, and it has a load of really good service worker related stuff in devtools.
This is a proposal for a lightning talk at the Reactive 2016 conference.
NOTE: If you like this, star ⭐ the Gist - the amount of stars decides whether it makes the cut! You could also Retweet if you want :)
JavaScript is a dynamic language, and there's nothing wrong with that. It allows quick iteration and lowers barriers. However, sometimes some compile-time type checking is just what you need to keep your code in line and give yourself the confidence to build bigger and faster. Flow gives the best of both worlds. You can have normal JavaScript but you can also add types where they're helpful, and it adds zero cost at runtime. In this talk I'll show Flow as it applies to a Redux & React codebase.
// Now your action creators can pull utilities our of their thunk api! | |
export function fetchUser(id) { | |
return ({api, dispatch}) => | |
api.fetch(`users/${id}`).then(resp => | |
dispatch({action: FETCH_USER, user: resp.body.data})); | |
} |
Most props on a JSX element are passed on to the component, however, there are two special props (ref
and key
) which are used by React, and are thus not forwarded to the component.
For instance, attempting to access this.props.key
from a component (eg. the render function) is not defined. If you need to access the same value within the child component, you should pass it as a different prop (ex: <ListItemWrapper key={result.id} id={result.id} />
) While this may seem redundant, it's important to separate app logic from reconciling hints.
{ | |
"keys": ["tab"], | |
"command": "expand_abbreviation_by_tab", | |
// put comma-separated syntax selectors for which | |
// you want to expandEmmet abbreviations into "operand" key | |
// instead of SCOPE_SELECTOR. | |
// Examples: source.js, text.html - source | |
"context": [ | |
{ |
Service Worker - offline support for the web
Progressive apps - high-res icon, splash screen, no URL bar, etc.
This is a proposal for a lightning talk at the Reactive 2015 conference.
NOTE: If you like this, star ⭐ the Gist - the amount of stars decides whether it makes the cut!
Relay makes data fetching in React apps simpler, by letting you declare the data needs of your components instead of writing complex imperative code. React, Relay, GraphQL and the other complementary tools are changing how apps are built.
import React, { Component } from 'react'; | |
import { createStore, combineReducers, applyMiddleware, bindActionCreators } from 'redux'; | |
import { provide, connect } from 'react-redux'; | |
import thunk from 'redux-thunk'; | |
const AVAILABLE_SUBREDDITS = ['apple', 'pics']; | |
// ------------ | |
// reducers | |
// ------------ |