This is a temporary solution. Might change in the near future, this depends on how create-react-app will implement testing.
create-react-app quick-test-example
cd quick-test-example
npm run eject| import React from 'react'; | |
| import { shallow } from 'enzyme'; | |
| import MyComponent from '../src/my-component'; | |
| const wrapper = shallow(<MyComponent/>); | |
| describe('(Component) MyComponent', () => { | |
| it('renders without exploding', () => { | |
| expect(wrapper).to.have.length(1); | |
| }); |
| import React from 'react'; | |
| const MIN_SCALE = 1; | |
| const MAX_SCALE = 4; | |
| const SETTLE_RANGE = 0.001; | |
| const ADDITIONAL_LIMIT = 0.2; | |
| const DOUBLE_TAP_THRESHOLD = 300; | |
| const ANIMATION_SPEED = 0.04; | |
| const RESET_ANIMATION_SPEED = 0.08; | |
| const INITIAL_X = 0; |
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.
NOTE: This is no longer an experiment! You can use the accessibility inspector in Chrome Devtools now, including a fantastic color contrast inspection tool. Read more: https://developers.google.com/web/updates/2018/01/devtools#a11y
Just like any good element inspector helps you debug styles, accessibility inspection in the browser can help you debug HTML and ARIA exposed for assistive technologies such as screen readers. There's a similar tool in Safari (and reportedly one in Edge) but I like the Chrome one best.
As an internal Chrome experiment, this tool differs from the Accessibility Developer Tools extension in that it has privileged Accessibility API access and reports more information as a result. You can still use the audit feature in the Chrome Accessibility Developer Tools, or you could use the aXe Chrome extension. :)
To enable the accessibility inspector in Chrome stable:
| import CreateInput from './Input.jsx'; | |
| const emailProps = { | |
| type: "email", | |
| inputMode: "email", | |
| name: "email", | |
| autoComplete: "email", | |
| pattern: "[a-zA-Z0-9_]+(?:\.[A-Za-z0-9!#$%&'*+/=?^_`{|}~-]+)*@(?!([a-zA-Z0-9]*\.[a-zA-Z0-9]*\.[a-zA-Z0-9]*\.))(?:[A-Za-z0-9](?:[a-zA-Z0-9-]*[A-Za-z0-9])?\.)+[a-zA-Z0-9](?:[a-zA-Z0-9-]*[a-zA-Z0-9])?", | |
| spellCheck: false, | |
| autoCorrect: "off", |
NOTE: Your mileage may vary, depending on project, and/or perhaps you prefer a different IDE altogether.
The principles here are what we're shooting for, not necessarily that everything be used verbatim.
In the interest of automating code quality, and cutting down on the necessity for manual code reviews, we strongly urge each front-end developer to install these Sublime Text packages.
| if ( | |
| process.env.NODE_ENV === 'production' && | |
| window.__REACT_DEVTOOLS_GLOBAL_HOOK__ && | |
| Object.keys(window.__REACT_DEVTOOLS_GLOBAL_HOOK__._renderers).length | |
| ) { | |
| window.__REACT_DEVTOOLS_GLOBAL_HOOK__._renderers = {} | |
| } |
| // Vanilla version of FitVids | |
| // Still licencened under WTFPL | |
| // | |
| // Not as robust and fault tolerant as the jQuery version. | |
| // It's BYOCSS. | |
| // And also, I don't support this at all whatsoever. | |
| ;(function(window, document, undefined) { | |
| 'use strict'; | |
With the release of Node 6.0.0, the surface of code that needs transpilation to use ES6 features has been reduced very dramatically.
This is what my current workflow looks like to set up a minimalistic and fast microservice using micro and async + await.